|My suggestion was intended for the Rabbit Hole and originally
|meant to be used with commit options B/C in case there are
|multiple bean instances when Rabbit Hole is finished.
yes, that would be interesting.
|Multiple instances would be not very usefull with pessimistic
|locking done on the DB, as the pessimistic behaviour (and locking
|waiting without a message) simply would remain viewed from the
|clients perspective.
precisely, I already fought with Vinay the "many instances speedup fallacy"
it's a lie...
if you don't break the pessimistic locking at the db then it is useless.
|But maybe Bill is right, OL could be used with commit option A
|and single bean instances too? I'm not really sure ... no I
|don't think so, because then every TX is working on state
|possibly modified by another TX and, even worse, with one
did he propose that? I don't think so (could be) in any case I am rewriting
the cache and one option would have to be a cache that upon looking up an
instance if there is a transaction associated with it would clone (deep
copy) the current instance so that each tx has a copy IN THE CACHE, this way
the container flow is un-affected.
Of course that supposes that we rely on the databases to synchronize the
updates, for that we need to know that transaction isolation work properly
across dbs.
btw this is why I am refactoring (rewriting really) the code in there. Well
the first reason is to get rid of the busy wait bug, but the nice by product
is that you can use the right cache with the right database. I sent a small
note yesterday on the transaction isolation... did you guys see it?
marcf
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
