I am running into another odd problem, this time it looks like ejbLoad() is
being called on a modified entity with out ejbStore() being called first.
I am not really sure why this would happen, nor do I know where to start
looking.
I am using isModified() to show that an entity has changed. The current
impl simply logs a message and returns a boolean flag. I implemented a
setModified(), which sets that flag to true and logs a message. I am seeing
bean is modified message, then shortly after on the same entity I see an
ejbLoad() but there is no message about checking if the entity has been
modified.
This might be caused by two different threads accessing the bean, so the tx
might be confused... but it is my understanding that this should work.
Essentially one user thread invokes a SFSB in a loop. This bean creates
jms messages. A MDB on another machine does something with the message and
sends a response message back. Then another MDB in the same VM as the SFSB
takes the message and updates 3 entities that were created by the SFSB to
track the message.
Due to this problem, the bookkeeping for the messages are inconsistent, which
more or less breaks the application completely.
Is it possible that this might be caused by the new locking system? I am
currently use the QueuedPessimisticEJBLock locking policy on all entities.
I might try SimplePessimisticEJBLock, but I wanted to get some input from
the experts first, as to why this might be happening.
At first I thought that there might be more than one Entity per PK being
created, but I am not seeing that.
If someone could advise me on where I can look to find out more how this
works it would really be appreciated.
--jason
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
