Hello,
Thank you for your answer and patience.
Just to answer to your questions, yes, there probably is a deadlock in the database. As I am using JMS there, one update was blocking another but none of the updates took that long (I'm not yet completely sure where a transaction starts and, more importantly, where it ends in my case). All the components are packaged in the same EAR but "StandardInstrument" is using a remote reference. The thing is that this class can be used from a 'detached' client or from within the enterprise application. I am aware that this might be a problem (at least an optimization problem). Could I solve this by using two service locators that would provide access to the EJBs, one would be used by the client and provide remote instances and another one within the enterprise application that would provide local instances? I would use this in a number of places. If so, what data types should these locators return? And yes, the two beans belong to the same PU.
What I'm using now is an EJB that updates one instrument at a time, this solves the blocking problem and there is one transaction for each of the instruments but I'm not very satisfied, I would like to understand what's going on.
By the way, if I use a service locator that's using caching for optimization so that every time the same instance will be provided, what happens if that instance is used for database updates (CRUD) and it is called from a JMS or multithreaded environment in a client? I know that EJBs are thread safe I could use more info.
Thank you,
[Message sent by forum member 'coboo' (coboo)]
http://forums.java.net/jive/thread.jspa?messageID=299745