JTA Transaction query
in [Java Help]
|
From: gk on 13 Aug 2010 13:08 On Aug 13, 6:44 pm, Owen Jacobson <angrybald...(a)gmail.com> wrote: > On 2010-08-13 08:37:38 -0400, gk said: > > > Here I have a query in simple JTA Transaction . I am reading from > > the book "Beginning Spring Framework 2" By Thomas Van De Velde, > > Bruce Snyder, Christian Dupuis, Sing Li, Anne Horton . > > > There is one section where I'm confused . I have written my query > > along side the code. Please have a look at this book excerpt . This > > is a google book graphic print . > > Can you please stop doing this? Transcribing the code in question will > make it much easier for people to answer your questions. Since you're > getting answers for free, it's in your interest to make it easy. > > As for your question: when multiple transactional resources are in use > in a single JTA transaction (for example, when you're working with a > database and a message broker), JTA uses something called XA* to > coordinate commits and rollbacks. XA specifies a two-phase commit > mechanism that ensures that all transactional resources will commit a > transaction ("prepare" phase) before actually committing the > transaction ("commit" phase). > > As a result, the resources you're using in your transaction must > support XA transactions. Most transaction-capable systems do support it > (XA is widely used in enterprise apps), but there are a few that don't. > Attempting to use non-XA resources in an XA transaction will fail early > (and abort the transaction) rather than risking inconsistencies. Read > the documentation for your transactional services (JDBC drivers, > message brokers, JCA connectors, and so on) for information on how to > set them up for XA transactions. > > Some JTA implementations support adding a single non-XA resource into > an XA transaction; there is an implementation for this that is > transactionally safe provided no heuristic recovery has to happen. Read > the manual for your transaction manager (usually, part of your EE > container) for details. > > -o > > *http://en.wikipedia.org/wiki/X/Open_XA I thought the graphic link will be easy to understand by the people because they were nicely formatted. I put the query on the side the code concerned. I thought ,people can understand that very easily. Anyway , I'll try if this can be taken into texts otherwise. Thanks for your time . By the way, I became more confused after reading your post. My questions was very straightforward. What will be the outcome of that code ? If I code that way , will there be a rollback or not ? I appreciate your time and post .
From: gk on 13 Aug 2010 13:14 On Aug 13, 6:44 pm, Owen Jacobson <angrybald...(a)gmail.com> wrote: > On 2010-08-13 08:37:38 -0400, gk said: > > > Here I have a query in simple JTA Transaction . I am reading from > > the book "Beginning Spring Framework 2" By Thomas Van De Velde, > > Bruce Snyder, Christian Dupuis, Sing Li, Anne Horton . > > > There is one section where I'm confused . I have written my query > > along side the code. Please have a look at this book excerpt . This > > is a google book graphic print . > > Can you please stop doing this? Transcribing the code in question will > make it much easier for people to answer your questions. Since you're > getting answers for free, it's in your interest to make it easy. > > As for your question: when multiple transactional resources are in use > in a single JTA transaction (for example, when you're working with a > database and a message broker), JTA uses something called XA* to > coordinate commits and rollbacks. XA specifies a two-phase commit > mechanism that ensures that all transactional resources will commit a > transaction ("prepare" phase) before actually committing the > transaction ("commit" phase). > > As a result, the resources you're using in your transaction must > support XA transactions. Most transaction-capable systems do support it > (XA is widely used in enterprise apps), but there are a few that don't. > Attempting to use non-XA resources in an XA transaction will fail early > (and abort the transaction) rather than risking inconsistencies. Read > the documentation for your transactional services (JDBC drivers, > message brokers, JCA connectors, and so on) for information on how to > set them up for XA transactions. > > Some JTA implementations support adding a single non-XA resource into > an XA transaction; there is an implementation for this that is > transactionally safe provided no heuristic recovery has to happen. Read > the manual for your transaction manager (usually, part of your EE > container) for details. > > -o > > *http://en.wikipedia.org/wiki/X/Open_XA Also, I'm doing this transaction in Weblogic 10 server . It has XA support I know. What will happen in that case ? will there be a JDBC rollback even there was a commit because of the entire transaction fail ?
From: Lew on 13 Aug 2010 15:38 gk wrote: > I thought the graphic link will be easy to understand by the people > No one said it's not easy to understand. We say that it's inconvenient to have to switch channels to maintain context and to cite that to which we respond. > because they were nicely formatted. I put the query on the side the > code concerned. I thought ,people can understand that very easily. > It's not about understanding, it's about convenience. Make it convenient for people to answer your questions, as Owen suggested. > Anyway , I'll try if this can be taken into texts otherwise. > Do you have a keyboard? If so, then you already have your answer and you need spend no more time investigating - the material can indeed be typed into a text format. > Thanks for your time . By the way, I became more confused after > reading your post. My questions was very straightforward. What will be > the outcome of that code ? If I code that way , will there be a > rollback or not ? > There should be a rollback. Whether there actually will be a rollback depends on the caveats in Owen's answer. There isn't enough information in the magic-wand hand-waving ("// Carry out JMS operations") in the example you provided to ensure that those conditions are met, but clearly the book you cited intends that the "operations" in question be XA compliant. To be on the safe side, you should investigate your question with respect to actual library calls, not textbook "// magic happens" comments. You should follow Owen's advice to actually read the documentation for the actual products you actually intend to actually use. Here on Usenet we can point you to the path but we can't walk it for you. For further understanding of your questions here and in the followup post, use your favorite search engine and Wikipedia to look up "two- phase commit". One of the fundamental skills we assume in Usenet is the ability to look up further detail on key words and phrases you get in answers here, and the willingness to do so. -- Lew
From: Lew on 13 Aug 2010 18:33 Owen Jacobson wrote: >> Read the documentation >> for your transactional services (JDBC drivers, >> message brokers, JCA connectors, and so on) for information on how to >> set them up for XA transactions. >> ... >> Read the manual >> for your transaction manager (usually, part of your EE >> container) for details. gk wrote: > Also, I'm doing this transaction in Weblogic 10 server . It has XA > support I know. What will happen in that case ? will there be a JDBC > rollback even there was a commit because of the entire transaction > fail ? Owen Jacobson wrote: >> Read the documentation >> for your transactional services (JDBC drivers, >> message brokers, JCA connectors, and so on) for information on how to >> set them up for XA transactions. >> ... >> Read the manual >> for your transaction manager (usually, part of your EE >> container) for details. -- Lew
From: Owen Jacobson on 13 Aug 2010 18:46 On 2010-08-13 13:08:37 -0400, gk said: > On Aug 13, 6:44�pm, Owen Jacobson <angrybald...(a)gmail.com> wrote: >> On 2010-08-13 08:37:38 -0400, gk said: >> >>> Here I have a query in simple JTA �Transaction . �I am reading from >>> the book �"Beginning Spring Framework 2" �By Thomas Van De Velde, >>> Bruce Snyder, Christian Dupuis, Sing Li, Anne Horton . >> >>> There is �one section �where I'm confused . I have written my query >>> along side the code. �Please have a look at this book excerpt . This >>> is a google book graphic print . >> >> Can you please stop doing this? Transcribing the code in question will >> make it much easier for people to answer your questions. Since you're >> getting answers for free, it's in your interest to make it easy. >> >> As for your question: when multiple transactional resources are in use >> in a single JTA transaction (for example, when you're working with a >> database and a message broker), JTA uses something called XA* to >> coordinate commits and rollbacks. XA specifies a two-phase commit >> mechanism that ensures that all transactional resources will commit a >> transaction ("prepare" phase) before actually committing the >> transaction ("commit" phase). >> >> As a result, the resources you're using in your transaction must >> support XA transactions. Most transaction-capable systems do support it >> (XA is widely used in enterprise apps), but there are a few that don't. >> Attempting to use non-XA resources in an XA transaction will fail early >> (and abort the transaction) rather than risking inconsistencies. Read >> the documentation for your transactional services (JDBC drivers, >> message brokers, JCA connectors, and so on) for information on how to >> set them up for XA transactions. >> >> Some JTA implementations support adding a single non-XA resource into >> an XA transaction; there is an implementation for this that is >> transactionally safe provided no heuristic recovery has to happen. Read >> the manual for your transaction manager (usually, part of your EE >> container) for details. >> >> -o >> >> *http://en.wikipedia.org/wiki/X/Open_XA > > Anyway , I'll try if this can be taken into texts otherwise. Thank you. > Thanks for your time . By the way, I became more confused after > reading your post. My questions was very straightforward. What will be > the outcome of that code ? If I code that way , will there be a > rollback or not ? If your database server is set up correctly, and if your database driver is set up correctly, and if your message broker is set up correctly, and if your transaction manager is set up correctly, and if the specifics of your program allow for it, then either both the database and the message operation will commit, or both the database and the message operation will roll back. If the JTA provider has decided that a transaction cannot be committed (say, because one of your messaging operations fails and invalidates the transaction), then the call to userTransaction.commit() will raise an exception, as documented at http://download.oracle.com/javaee/6/api/javax/transaction/UserTransaction.html#commit() .. -o
|
Pages: 1 Prev: JTA Transaction query Next: Cheap TEST BANKS AND SOLUTION MANUAL (scam) |