Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] EclipseLink data-source usage


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.

Rick

On Thu, Oct 16, 2014 at 9:40 AM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:

On 10/7/2014 10:33 AM, Rick Curtis wrote:
I don't think this matters, but I was running with <shared-cache-mode>NONE</shared-cache-mode>. 

To summarize what you said... until something is written to the transaction the read connection will be used? This seems very inefficient because in my case, making 5 subsequent trips to the database will result in 5 connections being opened/closed. Connection pooling helps with some of this performance hit, but pools are still slower than no pool.
On the contrary, the object read through read connection lands in L2 cache, therefore next time find is called (unless refresh query hint is specified) it fetches the object directly from the cache (= no trip to the db).
If you don't want to use shared cache (or just always want to reads through the write connection) there is a couple of alternative options:
1. specify puProperty "eclipselink.jdbc.exclusive-connection.mode" "Always";
2. specify puProperty "eclipselink.transaction.join-existing" "true" (note that also could be done on per entity manager basis)



Can I just not configure a non-jta-data-source or are there any scenarios that require use of a non-jta-data-source?

Thanks,
Rick

On Tue, Oct 7, 2014 at 9:22 AM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:
The described scenario is default one (exclusive connection is not).
When nothing has been written yet inside transaction find by pk is done in L2 cache first, if not found there - in the db, but through reading connection (and result merged into L2 cache).


On 10/7/2014 10:13 AM, Rick Curtis wrote:
I have been doing some testing on EclipseLink around datasource usage (jta vs non-jta) and there is a scenario that I don't quite understand. 

It scenario involves a SLSB method that has @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). I found that if inside of that method I do a number of em.find(..) operations, each operation gets a new (non-jta) connection. If I start the method with an em.persist(...);em.flush(); followed by a number of em.find(...) operations all of follow on em.find(...) calls use the one connection(jta). From what the documentation states (eclipselink.jdbc.exclusive-connection.mode), the default EclipseLink behavior is to send all reads/writes through an exclusive connection when running inside of a transaction. What am I missing?

Are there any best practices around the use of jta/non-jta datasources when using a JTA EntityManager?

Thanks,
Rick

--
Rick Curtis


_______________________________________________
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


_______________________________________________
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



--
Rick Curtis


_______________________________________________
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


_______________________________________________
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



--
Rick Curtis


_______________________________________________
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


Back to the top