aspose file tools*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Core J2EE Patterns: transactions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Core J2EE Patterns: transactions" Watch "Core J2EE Patterns: transactions" New topic
Author

Core J2EE Patterns: transactions

Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Hello All,

I have a question about where to put the container managed transaction within the business tier patterns. For example, chapter 7 of "Core J2EE Patterns" explains the ApplicationService pattern. So, for example you can have:

SLSBFacade->ApplicationService-> DAO or Entity

Chapter 7 has said that an ApplicationService is a POJO. So where is the transaction method? SLSBFacade is too generic to put detailed transaction handling. Should the following be used instead?

SLSBFacade->SLSBApplicationService->ApplicationService-> DAO or Entity

Will this be too slow with 2 SLSB in the chain?

Thanks for you help.

-Saha
s khosa
Ranch Hand

Joined: May 15, 2003
Posts: 72
My 2 cents. I would not complicate it that much. I personally think Part2 needed not be overkilled with too many patterns. I would think about putting a custom pattern with a TransactionController which initiates/rolls back transaction and this interacts with SessionBean for all transactional aspects that your system needs. You can differ whether this is the best solution but looking at effort vs benefit, i think this would work fine.

Thanks
Rama Bhargav
Greenhorn

Joined: Mar 25, 2006
Posts: 25
Saha,
I am in agreement with you when you proposed

SLSBFacade-->Service/App specific SLSB/SFSB--->pojo-->DAO/Entity. The SFSB facade too generic and will be used by all clients to access the business tier services. Facade in turn delegates to appropriate EJB (SLSB/SFSB). This is how most of the real time projects are implemented.
Rama Bhargav
Greenhorn

Joined: Mar 25, 2006
Posts: 25
Just to add to my above post, we provide transactional support declaratively to each method of Service/App specific SFSB/SLSB. And this transactional context will be carried to the subsequent components in the call chain like POJO/DAO/Entity beans.
Raghubir Bose
Ranch Hand

Joined: Feb 18, 2006
Posts: 88
when you say POJO you mean that these objects are value objects that are DTO's or VO's that will be transferred back and forth between the Entity Bean and the session bean ?


I will meet the fairy queen soon !
Raghubir Bose
Ranch Hand

Joined: Feb 18, 2006
Posts: 88
And another question when you say real time did you actually mean real life or real "real time" .. I have heard that J2EE is still not used for real time systems ... its still C++ , CORBA and TPF...

Please provide your comments.
Rama Rao Yadlapalli
Greenhorn

Joined: May 07, 2003
Posts: 3
Bose,

I did not use the term POJO correctly. It should have been any Java class that provides the desired Application Service with value objects (POJOs).

When I said real time, I meant real life projects.

As far as I am aware, J2EE is used for real time projects (I do not mean real critical missions that need very high precision), but general/common commercial applications that need a real time response with a tolerance of about 1-5 secs and where the stakes are not high in case of a failure, but for a slight inconvenience to the user.
Raghubir Bose
Ranch Hand

Joined: Feb 18, 2006
Posts: 88
Yes this is actually true for a commercial user ...who does not care much ...but there are some users to whom it matters like the Stock Brokers ...I do not know of any online stock exchange systems being developed in J2EE..

Slight off board .. but the point is predictability

It is said "A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred

Hence, it is essential that the timing constraints of the system are
guaranteed to be met. Guaranteeing timing behavior requires that the system
be predictable. It is also desirable that the system attain a high degree of utilization while satisfying the timing constraints of the system."

J2EE servers claims to be predictable ..but are they ???

http://www.mrtc.mdh.se/publications/0710.pdf
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Hello All,

Thank you for the responses. Sorry for getting back to you late.

s khosa - In which component would you put the custom transaction handler as you mentioned? This is good idea, but again, which component contains it? The ApplicationService is defined in Core Patterns as being a POJO...so no transaction there.

The term POJO is plain old java object, as compared with EJB component. A POJO does not have any of the J2EE features: security, transaction, etc.
s khosa
Ranch Hand

Joined: May 15, 2003
Posts: 72
It would a simple java component using Transaction API. And i would presume any EJB object e.g SessionBean when it has to bill user or update user Mileage account can initiate a transaction using it.

Thanks
Saha Kumar
Ranch Hand

Joined: Feb 23, 2006
Posts: 218
Thank you s khosa for the great information. I will ponder this further.

-Saha
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Core J2EE Patterns: transactions