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 the provider checks it before committing. 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.
