tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@tomitribe.com>
Subject Re: JDBC Transactions vs EJBs and @TransactionAttribute(...) and more...
Date Thu, 16 Oct 2014 12:05:02 GMT
2014-10-16 13:20 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> 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 <
> rmannibucau@tomitribe.com> 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 <itsmeden@gmail.com>:
>> > 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 <
>> rmannibucau@gmail.com>
>> > wrote:
>> >
>> >> 2014-10-16 9:31 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
>> >> > @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 <
>> >> rmannibucau@gmail.com>
>> >> > 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 <itsmeden@gmail.com
>> >:
>> >> >> > 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 <
>> >> >> rmannibucau@gmail.com>
>> >> >> > 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 <
>> itsmeden@gmail.com
>> >> >:
>> >> >> >> > 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, 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 itsmeden@gmail.com, and destroy all copies of this
> message and any attachments.

Mime
View raw message