efip10,
Sorry, I used too broad a brush.
At least in some cases, the behavior I described is dependent on the isolation
level selected. If at least level 2 ("read-committed") is selected, then I
think it works as I described, if the database supports it. I believe that
row-locking is used internally to the database to prevent concurrent access
during the commit. Everything is written first, and then everything is
unlocked. Thus if the race goes the wrong way, the early reader will block
until the late writer has finished. I don't know about MySQL's behavior in
this area.
While I think that JBPM is supposed to work
with any isolation level, its default isolation level is 1
("read-uncommitted"), and so there's much more experience with that level. The
level for JBPM is set as hibernate property hibernate.connection.isolation. I
don't know where isolation level for a database-persisted queue is dealt with
for JMS - AFAICT, it's either vendor-specific, or it's automatically set to
"read-committed" if this isolation level is supported. For JBoss messaging, I
haven't found where it's set, but see
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/guide/html_single/index.html#startingtheservice
for more info. I don't know how current it is.
Please share back whatever you find out!
-Ed Staub
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4066963#4066963
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4066963
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
