• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Distributed transactions for checkout

 
Nick Goupinets
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Ranchers,

Has anybody considered utilizing distributed transactions for the checkout process (Big Smokes)? I am not sure if Java EE support heterogeneous systems reasonably well for this. The following steps must be carried out:

1. Process payment by calling a bank web service (assuming that service has WS-Transaction / WS-Coordination support)
2. Update inventory information via an EJB (assuming inventory provides a compliant Java EE connector)
3. Send request to the shipping service via either a WS or Java client API (again, assuming that both support some form of TX handling)

Is it reasonable to assume that all this can run in a single distributed JTA transaction, facilitated by the app server? Or is it a wiser decision to architect a make-up business logic for each of the steps?

Thanks so much in advance.
Nick
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But that simply boils down to the question - can java ee manage a transaction between a web service, an ejb and a client call. Is that your question ? Did you research that
 
Nick Goupinets
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for refining the question, Master Deepak. It is the truth that the best way to educate your pupils is to let them educate themselves.

There is quite a bit on distributed transactions, transaction manager, two-phase commit, etc. Google is our friend, as always (no even mentioning the standard SCEA readings that talk about TXs):

http://archive.devx.com/java/free/articles/dd_jta/jta-2.asp
http://docs.sun.com/app/docs/doc/819-3669/bncgs?a=view
http://www.datadirect.com/developer/jdbc/topics/jta/dist-trans/index.ssp

, but unfortunately I can't find a good tutorial about TXs in heterogeneous systems. Hence I wanted to confirm from hopefully competent sources that it's at all possible.

I see no reason why there should be any issues propagating TXs between WS/DB. A JCA 1.5 compliant implementation should provide a TX manager, and finally Java clients can propagate transactions. So technically, each piece is transactional on its own. The other question is if it can be mixed together in a single transaction...

Thanks once again for your reply.
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I found this article -> http://www.ibm.com/developerworks/library/ws-transjta/

Figure 2 - Using a JTA transaction with a WS-AtomicTransaction transaction seems to be close to what you are asking.
 
Nick Goupinets
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Deepak,

Thank you for taking time to investigate and post here. This is an interesting article, and seems to answer my question

However, J2EE servers are not required to deal with non-J2EE invocations. There are some J2EE servers that can make exceptions; for instance, the WebSphere Application Server will correctly deal with an inbound CORBA request with an associated CORBA compliant transaction, propagating this transaction onto the thread and performing transactional work under its context. In most cases, however, you have to look beyond JTA and JTS when trying to move between transactional models, which is where Web services come in.


So it looks like transactions can be distributed across XA-compliant databases only, and with some proprietary / additional (i.e. not out-of-the-box Java EE) support, across web service calls. Which pretty much renders it of limited use for the SCEA Part 2. So the answer is to build the "rollback" logic manually for that use case.

Does it make sense ? Has anybody else built it similarly?

BTW, here is another interesting article http://blogs.sun.com/theaquarium/entry/distributed_transactions_between_glassfish_and

Thanks so much once again.

Regards,
Nick.
 
Deepak Bala
Bartender
Posts: 6663
5
Firefox Browser Linux MyEclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually the piece of text you quoted warns that if there are non J2EE elements involved in a transaction. the JTA spec need not take care of that. Here is a quote that should answer your question

The solution is a new technology called Web Services Transaction (WS-Transaction). This technology is the bridge between Web services and transactions. It is able to coordinate a transactional context that can be used by Web Services, other J2EE components such as EJB components and even other non-J2EE transaction services which support WS-Transaction.
 
Nick Goupinets
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Deepak,

Thank you very much for your clarification. Not sure if we are in the same timezone, but the timestamp for your reply shows 1:06 AM. So additional thanks for taking your precious sleep time to help.

Sorry, got confused by the implementation details . So WS-Transaction / WS-Coordination are part of JAX-WS http://www.predic8.com/axis2-cxf-jax-ws-comparison.htm, so it's safe to use it for Part 2. I am now reassured that transactional context can be shared between an EJB and WS in my diagrams .

Regards,
Nick.
 
Bigwood Liu
Ranch Hand
Posts: 240
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Nick. I agree with your solution: manually roll back

I guess BMT makes more sense here. reason:
1. we need transaction which includes all the processing procedures
2. heterogeneous XR transaction, such as web services transaction, is not supported well in JEE
3. I have a different concept against "Transparent transaction": Transaction is essentially a non-transparent logic, meaning user have to decide where and when it starts and ends. Transparent transaction has been advocated in EJB, which says that user should not consider transaction, they only consider business logic, and transaction is added by declarative way. I am not quite convinced by this sounds-good idea: transaction is conceptually similar to synchronization more or less: they promote isolation (transaction has more to consider). What is best practice for synchronization? put a "synchronized" on the signature of methods? which is not recommended, so is "transparent transaction".

In addition, although a crucial business method like "checkOut" demarcate a transaction, it will deal with heterogeneous XR, which in many cases are not supported well (like our case).

A best practice is not to mix BMT with CMT in an application, provided that is true, BMT is always a recommended way in any non-trivial application.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic