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 13:42:13 GMT
hehe you are curious, read
org.apache.openjpa.kernel.BrokerImpl#beforeCompletion. It basically
check all state of the entities
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau



2014-10-16 15:38 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
> Thanks for the answer
>
> What exactly is involved in a checkDs1() call?
>
> Regards
> LF
>
> On Thu, Oct 16, 2014 at 3:33 PM, Romain Manni-Bucau <
> rmannibucau@tomitribe.com> wrote:
>
>> 2014-10-16 15:01 GMT+02:00 Lars-Fredrik Smedberg <itsmeden@gmail.com>:
>> > Thanks again, see below.
>> >
>> > On Thu, Oct 16, 2014 at 2:05 PM, Romain Manni-Bucau <
>> > rmannibucau@tomitribe.com> wrote:
>> >
>> >> 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
>> >>
>> >
>> > 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 <
>> >> > 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.
>> >>
>> >
>> >
>> >
>> > --
>> > 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