2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: > Thanks again, see below. > > On Thu, Oct 16, 2014 at 2:05 PM, Romain Manni-Bucau < > [email protected]> wrote: > >> 2014-10-16 13:20 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: >> > Just one more thing I forgot to put in the other mail >> > >> > With "Depend, using ManagedConnection it will be green but it will not >> do what >> > you expect." you mean that I will think it runs in a tx but its not and >> in >> > case of failure I might get inconsistency? >> > >> >> right, if datasource2.commit() fails but ds1.commit() passed then you >> are not consistent. Of course with jpa it is not that impacting since >> > > Could you please explain how jpa tries to solve this? I guess it will not > completely remove the consisitency risk but only lower the risk? >
It doesn't but it limits it in practise. It basically do a check before calling commit. All checks pass before commit: checkDs1(); checkDs2(); commitDs1(); commitDs2(); so it avoids half of the ds2 commit fails but not ds1. > >> the provider checks it before committing. >> >> > So I guess in our case: non xa datasources with multiple connections within > a transaction we are not guaranteed consistency? > Yep > I see also that some db vendors (MQ SQL) has some optimization so > transactions involving multiple connections from different datasources but > from the same db is not promoted to a distributed tx > > => Is that only vendor specific or is that according to spec to not promote > it in certain situations? > vendor > > resource = datasource != underlying db (without using openejb >> aliases). Each datasource has its own pool of connection and then its >> own JTA integration (different Xid). >> >> > Regards >> > LF >> > >> > On Thu, Oct 16, 2014 at 12:59 PM, Romain Manni-Bucau < >> > [email protected]> wrote: >> > >> >> Well I don't know websphere enough to answer to the related question >> >> >> >> >> >> 2014-10-16 12:55 GMT+02:00 Lars-Fredrik Smedberg <[email protected]>: >> >> > Thanks Romain, please see if you can help me on the follow up below? >> >> > >> >> > >> >> > On Thu, Oct 16, 2014 at 9:33 AM, Romain Manni-Bucau < >> >> [email protected]> >> >> > wrote: >> >> > >> >> >> 2014-10-16 9:31 GMT+02:00 Lars-Fredrik Smedberg <[email protected] >> >: >> >> >> > @Romain >> >> >> > >> >> >> > I can see in the ManagedConnection code that the reused Connection >> is >> >> per >> >> >> > Transaction per DataSource. >> >> >> > >> >> >> > So if I use 2 x DataSource (pointing to the same DB but with >> different >> >> >> > properties set) I will within a transaction use 2 connections, >> >> correct? >> >> >> > >> >> >> yep >> >> >> >> >> >> > Will this result in a distributed transaction? >> >> >> > >> >> >> >> >> >> No, this ManagedConnection is to get JTA integration "locally" (ie we >> >> >> integrate locally with XA hooks but it is not distributed). For that >> >> >> you have to use a really XA datasource. >> >> >> >> >> > >> >> > We use WebSphere in test/production and the driver included in >> >> db2jcc4.jar. >> >> > >> >> > As far as I understand from the documentation if the type attribute of >> >> the >> >> > datasource element in the configuration is not set it will search the >> >> > driver jar for datasources in the following order: >> >> > >> >> > javax.sql.ConnectionPoolDataSource >> >> > javax.sql.DataSource >> >> > javax.sql.XADataSource >> >> > >> >> > In our testconfiguration we do not specify the type attribute so I >> assume >> >> > we are NOT using XA datasource. correct? >> >> > >> >> > So some questions on the above: >> >> > >> >> > 1. In what cases will I not need a distributed tx? >> >> >> >> You don't need it either when you have a single or totally decorelated >> >> resources (datasource for instane) or when you want performances (XA >> >> is slow) and can accept some manual operations to fix inconsistency if >> >> it happens (should be rare) >> >> >> >> > a) A tx with 1 connection to a DB? No! >> >> > b) A tx with 2 connections (from seperate datasources) connected to >> the >> >> > same DB? <== ?? >> >> > c) A tx with 2 connections (from seperate datasources) connected to >> >> > different DBs? Yes! >> >> > d) A tx with 1 connection to a DB and e.g. JMS? Yes! >> >> > >> >> > 2. If I have a scenario that requires a distributed and the datasource >> >> that >> >> > is used is NOT an XA datasource what will happen? Exception? >> >> > >> >> >> >> Depend, using ManagedConnection it will be green but it will not do >> >> what you expect. >> >> >> >> > Thanks >> >> > >> >> > Regards >> >> > Lars-Fredrik >> >> > >> >> > >> >> > >> >> >> >> >> >> > Regards >> >> >> > LF >> >> >> > >> >> >> > On Wed, Oct 15, 2014 at 8:48 AM, Romain Manni-Bucau < >> >> >> [email protected]> >> >> >> > wrote: >> >> >> > >> >> >> >> Hi >> >> >> >> >> >> >> >> that's the global idea yes >> >> >> >> >> >> >> >> about transaction manager: >> >> >> >> >> >> >> >> >> >> >> >> >> >> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.geronimo.components/geronimo-transaction/3.1.1/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java#TransactionManagerImpl >> >> >> >> is th eone >> >> >> >> >> >> >> >> idea is simple: invoke registered hooks when needed and just >> manage >> >> >> >> the lifecycle then EJB containers start/stop these hooks calling >> the >> >> >> >> tx mgr (look SingletonContainer hierarchy in openejb-core for >> >> >> >> instance) >> >> >> >> >> >> >> >> >> >> >> >> Romain Manni-Bucau >> >> >> >> @rmannibucau >> >> >> >> http://www.tomitribe.com >> >> >> >> http://rmannibucau.wordpress.com >> >> >> >> https://github.com/rmannibucau >> >> >> >> >> >> >> >> >> >> >> >> 2014-10-15 1:19 GMT+02:00 Lars-Fredrik Smedberg < >> [email protected] >> >> >: >> >> >> >> > Hi Romain >> >> >> >> > >> >> >> >> > Thanks for the link to the ManagedConnection, some questions on >> it >> >> >> (so I >> >> >> >> > understand it correctly) >> >> >> >> > >> >> >> >> > - The connection is bound to the tx when the first method is >> >> called on >> >> >> >> the >> >> >> >> > connect (except for toString, equals and hashcode), and if its >> not >> >> >> >> already >> >> >> >> > bound, correct? >> >> >> >> > - Do I understand correctly that I will always use (using >> >> delegation >> >> >> in >> >> >> >> the >> >> >> >> > proxy) the same connection (the one bound to the tx) regardless >> of >> >> if >> >> >> I >> >> >> >> use >> >> >> >> > getConnection()/close() multiple times within an EJB that >> handles >> >> tx? >> >> >> >> > - In the above case the connection I think I'm using (when I >> simple >> >> >> look >> >> >> >> at >> >> >> >> > the code) is returned to the pool and the bound one is used? >> >> >> >> > >> >> >> >> > Where can I get more understanding of the TransactionManager and >> >> its >> >> >> >> > relation to the transactions annotated in the EJB? >> >> >> >> > >> >> >> >> > Very nice to take a look at the code, really makes the >> >> understanding >> >> >> alot >> >> >> >> > easier, thanks! >> >> >> >> > >> >> >> >> > /LF >> >> >> >> > >> >> >> >> > >> >> >> >> > On Wed, Oct 15, 2014 at 1:03 AM, Romain Manni-Bucau < >> >> >> >> [email protected]> >> >> >> >> > wrote: >> >> >> >> > >> >> >> >> >> Hi >> >> >> >> >> >> >> >> >> >> this is actually more bound to JTA (you can read >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/resource/jdbc/managed/local/ManagedConnection.java >> >> >> >> >> ) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 2014-10-15 0:14 GMT+02:00 Lars-Fredrik Smedberg < >> >> [email protected] >> >> >> >: >> >> >> >> >> > Hi >> >> >> >> >> > >> >> >> >> >> > Using JDBC, creating a connection and setting it to auto >> commit >> >> >> false >> >> >> >> to >> >> >> >> >> be >> >> >> >> >> > able to group more than one statement into a single >> transaction >> >> I >> >> >> >> >> > understand. >> >> >> >> >> > >> >> >> >> >> > - Is it possible to compare that to an EJB with a >> >> >> >> @TransactionAttribute >> >> >> >> >> > set? I would like to understand more in detail how the EJB >> >> handles >> >> >> >> >> > transactions, datasources and connections "under the hood". >> >> >> >> >> > (it all comes from a discussion with a DBA) >> >> >> >> >> > >> >> >> >> >> > If I use @Resource to inject a Datasource and use to >> retrieve a >> >> >> >> >> connection >> >> >> >> >> > I usually call close on it after I done using it, >> >> >> >> >> > >> >> >> >> >> > - Will close on the connection actually close it or is that >> >> done at >> >> >> >> the >> >> >> >> >> > commit of the transaction (assume we are in an EJB with >> >> >> >> >> > @TransactionAttribute set)? >> >> >> >> >> >> >> >> >> >> will be done later to support rollback >> >> >> >> >> >> >> >> >> >> > - Will the container automatically set auto commit false to >> any >> >> >> >> >> connections >> >> >> >> >> > retrieved within the transaction? >> >> >> >> >> >> >> >> >> >> all JTA ones, can also depend on JPA provider config >> >> >> >> >> >> >> >> >> >> > - ... and many more questions :) >> >> >> >> >> > >> >> >> >> >> > Maybe I'm mixing the topics a bit but it would be really >> great >> >> to >> >> >> >> >> > understand it all more in-depth to be able to have the >> >> >> understanding >> >> >> >> and >> >> >> >> >> > discuss it with the DBA. >> >> >> >> >> > >> >> >> >> >> > Thanks >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > Med vänlig hälsning / Best regards >> >> >> >> >> > >> >> >> >> >> > Lars-Fredrik Smedberg >> >> >> >> >> > >> >> >> >> >> > STATEMENT OF CONFIDENTIALITY: >> >> >> >> >> > The information contained in this electronic message and any >> >> >> >> >> > attachments to this message are intended for the exclusive >> use >> >> of >> >> >> the >> >> >> >> >> > address(es) and may contain confidential or privileged >> >> >> information. If >> >> >> >> >> > you are not the intended recipient, please notify >> Lars-Fredrik >> >> >> >> Smedberg >> >> >> >> >> > immediately at [email protected], and destroy all copies of >> >> this >> >> >> >> >> > message and any attachments. >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > Med vänlig hälsning / Best regards >> >> >> >> > >> >> >> >> > Lars-Fredrik Smedberg >> >> >> >> > >> >> >> >> > STATEMENT OF CONFIDENTIALITY: >> >> >> >> > The information contained in this electronic message and any >> >> >> >> > attachments to this message are intended for the exclusive use >> of >> >> the >> >> >> >> > address(es) and may contain confidential or privileged >> >> information. If >> >> >> >> > you are not the intended recipient, please notify Lars-Fredrik >> >> >> Smedberg >> >> >> >> > immediately at [email protected], and destroy all copies of >> this >> >> >> >> > message and any attachments. >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Med vänlig hälsning / Best regards >> >> >> > >> >> >> > Lars-Fredrik Smedberg >> >> >> > >> >> >> > STATEMENT OF CONFIDENTIALITY: >> >> >> > The information contained in this electronic message and any >> >> >> > attachments to this message are intended for the exclusive use of >> the >> >> >> > address(es) and may contain confidential or privileged >> information. If >> >> >> > you are not the intended recipient, please notify Lars-Fredrik >> >> Smedberg >> >> >> > immediately at [email protected], and destroy all copies of this >> >> >> > message and any attachments. >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Med vänlig hälsning / Best regards >> >> > >> >> > Lars-Fredrik Smedberg >> >> > >> >> > STATEMENT OF CONFIDENTIALITY: >> >> > The information contained in this electronic message and any >> >> > attachments to this message are intended for the exclusive use of the >> >> > address(es) and may contain confidential or privileged information. If >> >> > you are not the intended recipient, please notify Lars-Fredrik >> Smedberg >> >> > immediately at [email protected], and destroy all copies of this >> >> > message and any attachments. >> >> >> > >> > >> > >> > -- >> > Med vänlig hälsning / Best regards >> > >> > Lars-Fredrik Smedberg >> > >> > STATEMENT OF CONFIDENTIALITY: >> > The information contained in this electronic message and any >> > attachments to this message are intended for the exclusive use of the >> > address(es) and may contain confidential or privileged information. If >> > you are not the intended recipient, please notify Lars-Fredrik Smedberg >> > immediately at [email protected], and destroy all copies of this >> > message and any attachments. >> > > > > -- > Med vänlig hälsning / Best regards > > Lars-Fredrik Smedberg > > STATEMENT OF CONFIDENTIALITY: > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of the > address(es) and may contain confidential or privileged information. If > you are not the intended recipient, please notify Lars-Fredrik Smedberg > immediately at [email protected], and destroy all copies of this > message and any attachments.
