Hi chris,
thanks for your reply, it was very helpful.
I remember now why we turned the shared cache off - we haven't implemented all management functionality yet and sometimes it is necessary to directly use SQL commands to modify data. With shared cache turned on (as described in the article), our application won't be aware of the changes unless we re-deploy it (or create some sort of refresh operation that would take care of that).
The application I'm working on is an attendance reporting tool. If an employee wants to view a week, the application automatically creates the Week and Day entities if they don't exist. This is the reason for the Entity already exists exception I think, because the first servlet created those entities and the other servlet isn't aware of that (due to first cache issues). It then attempts to create Day and Week entities as well (primary key is the date of the day, so the same) and crashes there.
I don't have a strategy yet to handle OptimisticLockExceptions, they are unhandled at the moment. Can you recommend a good strategy to handle them? I thought handling them on the client side and displaying an out-of-date message would be sufficient, since I don't know which values are the correct ones - those in the database or in the managed entity I try to persist.
One more question to the clear() method: aren't entities automatically detached at the end of a method, and re-attached when they're passed as parameters?
Thanks, Encey
[Message sent by forum member 'encey' (martin.enzelsberger_at_gmail.com)]
http://forums.java.net/jive/thread.jspa?messageID=386315