Hello,
after an upgrade from EclipseLink 2.3.2 to 2.5.2 we encountered something strange when a READ_ONLY query was executed inside a running transaction.
Attached is a sample app that tries to insert a record and then tries to query this via a READ_ONLY query
transaction.begin();
// create a new record and persist it
SomeEntity se = new SomeEntity();
se.setSomeValue("This is a new entity");
em.persist(se);
em.flush(); // force insert in the database, creates an id
// try to query this new record
Query query = em.createQuery("SELECT e FROM SomeValue e WHERE e.id = :id");
query.setParameter("id", se.getId());
query.setHint(QueryHints.READ_ONLY, HintValues.TRUE);
// query
SomeEntity justPersistedEntity = (SomeEntity) query.getSingleResult();
System.out.println(justPersistedEntity.getId());
transaction.commit();
What happens when query.getSingleResult() is executed that inside this (EclipseLink) transaction a new connection to the database is started on which this query is executed. Because 'se' is not yet committed it will not be readable by this new connection. However, I would expect this query would use the same transaction/connection as before.
With MySQL this results in a exception (NoResultException). On MS SQL Server the behaviour is even worse on a database with default settings, (READ_COMMITTED, READ_COMMITTED_SNAPSHOT = Off), it results in a deadlock.
In version 2.3.2 this works fine.
We suspect the cause of this behavior is bug issue number 382410 in version 2.4.1. (Sorry, adding the link here gives a post error)
Even though it might make sense to use a different connection for read_only queries, i would not expect this to happen when data is already modified in the transaction. Eclipselink knows when data has been altered.
Is this a bug or feature?
Chris
] 
Search
Help
Register
Login
Home
