On 10/16/2014 4:42 PM, Rick Curtis
wrote:
Andrei -
Thanks for the reply.
Is it a best practice to configure both a jta and a non-jta
datasource?
Yes.
Or does it not much matter?
You don't need heavy jta-managed connections for reading outside of
jts transactions.
The other reason it's a possibility to have a db transaction (on
nonjta ds) used from inside the scope of jta transaction, yet
independent from it.
That's used in Table sequencing:
Suppose concurrent threads 1 and 2 each have an active JTA
transaction and there is no more cached sequence values available.
That means both threads have to grab a new bunch of sequence values
from the db:
UPDATE SET seq_value = seq_value + increment WHERE seq_name = ..
SELECT seq_value WHERE seq_name = ..
Obviously the first to reach UPDATE locks out the second one for the
duration of the first thread's JTA transaction.
Note that it's impossible to share sequence numbers acquired in JTA
transaction with other threads because the transaction might
rollback.
With table sequencing using nonjts ds allocation of sequence numbers
performed in a separate db transaction, which commits immediately
and the acquired seq. numbers cached by Eclipselink -> shared
between all threads = no contention.
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
|