Sure, I can understand why it's doing it, but I was under an impression that
it's a violation of the contract for SERIALIZABLE. Am I wrong? (statistics
show that I am.. :D)
If we pretent do be a DB for just a moment, doesn't SERIALIZABLE dictate that
no other connection can create a new row in a table while a SERIALIZABLE
transaction is in progress? I could be way wrong here, but I thought that's
what the contract was, maybe it's only if one has read something from that
table.
Is there anyway I can implement the sort of behaviour I need? How can I
prevent 2 threads from even looking at the state of a Node in the cache while
some other thread has a lock on that Node.
What about if I synchronized(..) on the actual Node before inspecting? Could I:
Object node = cache.get("/SecurityInfo/" +myId);
synchronized(node) {
-- read value of node
--- do DB Lookup as necessary
}
If another Thread came along, I would hope it would block. Given that there
could me many many many 'myId's', I'd need to evict them after a while, but
long enough such that the get(..) call returned the exact same object for
multiple threads for the sync call to work.
Thanks for all replies. Thoughts would be very much appreciated.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3854894#3854894
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3854894
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
