Hello Encey,
Since both servlets are using the same stateless session bean, I do not believe you need to turn the shared cache off - it might be better for performance if you kept using it. The Second level cache (shared cache) is only one part. The other is that the entityManager itself has its own cache, in order to keep transactions issolated and to keep track of managed object identity.
Wonsoek wrote a good article on the TopLink cache that might help:
http://weblogs.java.net/blog/guruwons/archive/2006/09/understanding_t_1.html
The EntityManager cache means that if any other transaction commits after you have read in the entity in the current context, the changes won't be shown in the active EntityManager - unless you explicietly refresh the entity using the em.refresh api. This method though will wipe out any changes made to the managed entity in the current context though, so it should be used carefully. The other alternative is to call em.clear() which clears the cache, effectively detaching all managed entities. This will allow you to continue to use the entities without having changes wiped out, and reading back in entities will pick up changes (from either the shared cache or the database depending on your settings). When an OptimisticLockException is encountered, how does your application handle it? And how are you getting Entity already exists type problems - this implies a different problem. Entity exists are thrown when persist is called on an unmanaged yet existing object, which is an application error, so you should look at how this is happening.
Best Regards,
Chris
[Message sent by forum member 'chris_delahunt' (christopher.delahunt_at_oracle.com)]
http://forums.java.net/jive/thread.jspa?messageID=386140