Hi
Marc Fleury wrote:
> 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.
so this puts more stress on me to implement it, as it is usefull
already with multiple server instances. I still can't promise to
start that before next weekend.
> |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.
If I understand you right, you would keep an unmodified original
and give every TX a clone of that, right? As cloning, when the
second TX comes in, would be too late, the cached instance could
already been modified and then rolled back. Non TX threads get
what, the original? Or better a "clobber this when you don't know
what you are doing" clone handed out to every thread outside TX?
> 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.
Not sure what you mean here, several DBs in same TX? Nevertheless
I think the multiple instances cache would nicely fit together
with the optimisting locking, wether it is naturally done by the
DB or mimicked on top of pessimistic locking DBs (the latter
having some pitfalls, see my earlier message with the diagram).
Though I can't come up yet with a scenario where this will fail,
why does the EJB spec 1.1 section 9.1.11 suggest a correspondence
between commit option A and single bean instances? Does someone
have a hint?
> 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,
Really happy about that!
> 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?
yes, as you already might have seen from my other messages.
regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
