aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Designing Distributed Transaction Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Designing Distributed Transaction" Watch "Designing Distributed Transaction" New topic
Author

Designing Distributed Transaction

Alex Nunez
Greenhorn

Joined: Mar 01, 2005
Posts: 6
Hi all!

I need some help about the design of a global transaction. I can't find anything that fits me on internet.

The idea is about a servlet that has to update two databases on different servers (locations) where cmp beans are running.

What is the way to achieve that?

Do I have to start a transaction in the servlet and within this transaction perform the call on two session beans? Do the first session bean start the transaction itself and calls the second bean? Do I have to use Message-Driven Beans instead?

I guess the best way is to use cmt, tho I don't know a lot about it.

I'm a bit confused with all this stuff...
If someone knows a link with an example It would be greate.

THANKS!!!
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704

The idea is about a servlet that has to update two databases on different servers (locations) where cmp beans are running.

Are these two app servers the same, or they are different containers? If the containers are different, then this might never work, because J2EE doesn�t mandate that the container must support transactional context interoperability (it suggest it only). Hence check your containers� documentation first.
If you have the same type of container running on both servers, then you have to decide whether to use CMT or BMT. If you chose CMT then you are smart ;_) but in this case you cannot use a servlets, you need to implement an ejb component. (servlets doesn�t run within your application container and cannot make use of the EJB transaction attributes). The advantage of having a SLSB is that you don�t need to use any transactional API, the container will do the job for you. However if you�re more comfortable with servlet API you need to use JTA/JTS service (not JDBC API), start the transaction in your servlet, call the EJBs from both containers in the appropriate order,and finally commit the transaction. Don�t worry; the container will take care of the distributed transaction, via the 2PC protocol.

If someone knows a link with an example It would be greate.

Check this link from BEA.
http://edocs.beasys.com/wls/docs81/oracle/trxjdbcx.html
Although you�re not using WebLogic It will give you an idea about what�s going on. The example is at the bottom of the page, and all the code inside of the session bean will work inside of a servlet as well.


I think, therefore I exist -- Rene Descartes
Alex Nunez
Greenhorn

Joined: Mar 01, 2005
Posts: 6
Thank you very much for your reply. Documntation is often confusing, I really apreciate your help!

Both ejb containers are the same (i.e. S1AS7).

If I'm right, there are this 2 ways:

1) [JTA]
1. Servlet gets UserTransaction
2. Servlet calls begin
3. Servlet calls the two SLSBs
4. Servlet calls commit
(Servlet has stubs for SLSB 1 and 2)
(Rollback exceptions are handled in Servlet)

2) [CMT]
1. Servlet calls first SLSB
2. SLSB 1 starts transaction tranparently to the developper,
does some work on Entity Beans and calls SLSB 2
3. SLSB 2 does some work and when completed returns control to SLSB 1
4. SLSB 1 returns to servlet
(Servlet has stubs for SLSB 1 and SLSB 1 has stubs for SLSB 2)
(Rollback exceptions are handled in SLSB 1)

- What are the main differences?
- Is one of them more efficient than the other?
- Which one adds a higher decoupling level in app logic ?
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
OK with JTA scenario.

2) [CMT]
1. Servlet calls first SLSB
2. SLSB 1 starts transaction tranparently to the developper,
does some work on Entity Beans and calls SLSB 2

3. SLSB 2 does some work and when completed returns control to SLSB 1
4. SLSB 1 returns to servlet
(Servlet has stubs for SLSB 1 and SLSB 1 has stubs for SLSB 2)
(Rollback exceptions are handled in SLSB 1)

Do you have to change SLSB1 to make the call to the SLSB2, or the code already behaves this way? If this is the case, then you don�t need to do care about distributed transactions in your servlet at all, because SLSB1 will take care of everything.
I was thinking that in your application SLSB1 and SLSB2 are not coupled and they know nothing about each other. You might like considering this scenario:

2) [CMT]
1. MySLSB starts transaction tranparently to the developper and calls first SLSB.
2. SLSB 1 does its work and is a participant in the transaction initiated by MySLSB.
3. MySLSB calls second SLSB.
4. SLSB 2 does its work and it�s a participant in the same transaction initiated by MySLSB.
(MySLSB has stubs for SLSB 1 and 2)
(Rollback exceptions are handled by the MySLSB)

The only difference here is that you�ll replace your servlet with a SLSB and you won�t require writing any transaction logic. A very simple and clean SLSB that makes two calls to other SLSB and ensures that the transaction is well-committed or rolled back.
Please let me know if this scenario works for you, in order to answer to your questions.
Alex Nunez
Greenhorn

Joined: Mar 01, 2005
Posts: 6
Thanks very much for all your help!!

Well, I think I need the servlet since the client application is a MIDlet and I will make some changes for handling jsps as well.

Do you think your scenario would be feasible with a serlvlet? MySLSB and SLSB1 would be in the same container and SLSB2 in the other, am I right?

Would it overhead the system using this scenario?
Wouln't it be better to simply use JTA in the servlet?
One more issue: using JTA in the servlet, would the cmt/bmt issue be made irrelevant?

thanks so much!
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704

Do you think your scenario would be feasible with a serlvlet?

Sure.

MySLSB and SLSB1 would be in the same container and SLSB2 in the other, am I right?

Location doesn�t matter; you can have all of them deployed to the same container, or every one deployed to its own container, etc. Actually the location transparency is one of the J2EE aims. The only thing to consider is that deploying your beans to the same container, you can take advantage of the local interfaces and improve your system performances.

Would it overhead the system using this scenario?

Absolutely not.

Wouln't it be better to simply use JTA in the servlet?

The question actually is: do you want to use JTA, or you�d like not to bother about writing any transaction api at all (let the container handle it)? Adding one more component to your design (the MySLSB) then your servlet won�t need to care about transactions anymore: it will only make an RMI call invoking one method on your MySLSB. Because MySLSB uses CMT the container will start and managed the distributed transaction in client�s behalf (cool isn�t it?). So no JTA at all and this is the benefit of coding this extra SLSB.

One more issue: using JTA in the servlet, would the cmt/bmt issue be made irrelevant?

Not at all. Your servlet will start the transaction and will propagate the transactional context to other EJB components. From here on is the container�s (in CMT) or bean�s (in BMT) job to deal with this transaction. From the EJBs perspective there is no difference who instantiated this transaction: another local EJB, your servlet or another piece of client code.
And by the way, you�re very welcomed
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Designing Distributed Transaction