Hello,
You haven't mentioned the persistence provider being used, but the default in Glassfish is EclipseLink. EclipseLink uses a second level cache by default, which can cause confusion for some users when it is not taken into account. JPQL update statements do not modify entities directly - they are sent to the database and the shared cache is invalidated when the transaction commits. They do not affect the first level cache (local to the EntityManager), so the entity read in from the select query will always show col1='xyz' until it is cleared or refreshed. I can't say for certain what is going wrong if you are calling flush - is the second webservice call in a seperate application? If so, they will not be using the same shared cache (the shared cache is associated to the factory), and so the shared cache in the second service will never get invalidated. I don't see your transaction management, but is the thread commiting the transaction? If it is not, then transactional issolation will keep other threads from seeing the changes, and they will just rollback.
em.refresh is the easiest way to check if the returned entity still has col1='xyz', but you can also add a refresh query hint to the select query to ensure it gets its data from the database. There are also caching options you can change to help reduce stale data, but I would recommend you understand the application usage requirements before changing the defaults as they can drastically improve or hinder performance later on. Please see:
http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_(ELUG)#Using_EclipseLink_JPA_Extensions_for_Entity_Caching
and
http://wiki.eclipse.org/Introduction_to_Cache_%28ELUG%29
(where session cache=factory/second level cache, and UnitOfWork cache = em/first level cache).
Best Regards,
Chris
[Message sent by forum member 'chris_delahunt']
http://forums.java.net/jive/thread.jspa?messageID=475521