Hi,
David Jencks wrote:
> On 2001.06.28 08:32:18 -0400 Ole Husgaard wrote:
> > This algorithm may be fine, but it seems to be for commit
> > option A only.
> As written, yes, as you point out below, reloading from db for each new
> transaction is necessary for B/C
> >
> > I think we should also consider the other commit options,
>
> yes
Thinking some more, I do not see how we could support
snapshot isolation with other commit options than A
without some kind of special resource support for it,
because a reload is needed with the other options and
a later tx may have changed the DB before the reload,
thus violating the snapshot.
> > and optimistic/pessimistic locking.
>
> Not sure why we would want more pessimistic locking-isn't that what we have
> now?
Pessimistic and optimistic locking both have advantages,
and it would be nice if we could support both, maybe
with a per-container setting.
> > > transactions are numbered sequentially when they are started.
> >
> > Sorry, but I don't think we can rely on that if we need
> > to avoid dependencies on the transaction service used.
> >
> > (By hacking a special dummy XA resource that is
> > registered with every new tx seen by JBoss, I
> > guess we could get to the Xid, and maintain some
> > kind of mapping from the GlobalID to a serial
> > number. But that looks a bit ugly to me.)
>
> I agree this is a potential problem. However I think you don't get
> snapshot isolation and maybe you might get more deadlock opportunities
> without it. (I think just read committed isolation) I haven't really
> looked into it, but I wondered about using the transaction interceptors--
> this is where all new transactions come from, isn't it, and its definitely
> part of the container not the TM?
I guess that the problem with snapshot isolation is
that the "logical locking" happens at transaction
start, before anything is read or we even know what
is about to be read.
I have only been thinking about the case where only
a single container is involved in the transaction,
but such transactions may involve several containers,
and even several servers.
I cannot see how we could create transaction sequences
for multiple servers without some kind of centralized
ticket service, giving a single point of failure.
I have to warn against the obvious way of doing local
transaction numbering:
A server-wide WeakHashMap that maps Transaction to
Integer.
Problem with this is that there may not be a one-to-one
correspondence between Transaction instances and the
actual transactions they represent. Not long ago, the
fast in-VM TX service could create several Transaction
instances for the same transaction, and these different
Transaction instances could be active at the same time.
That is not a violation of the JTA specification. The
only sure way we can know if different instances are
the same transaction is by looking at the Xid of the
transaction. Unfortunately JTA only exposes that to
resources.
> > > When you change an entity, a new version is put in the cache with your
> > > transaction id ( of course no one else can see it till you commit: the
> > > entity versions need both the transaction sequence and some way of
> > telling
> > > if they are committed.).
> >
> > I guess we could call isModified() after each invocation
> > to avoid creating a new version until the entity is
> > actually modified.
> > But that means that we would use the same entity version
> > for different transactions, and since it is too late to
> > get the unmodified entity version after isModified()
> > returns true, wouldn't we have to create another version
> > before the invocation anyway?
>
> After I wrote this I thought about it some more. I think it can only be
> made to work with ejb 2 abstract accessors-- as you say I think for ejb 1.1
> beans we need each transaction to get a copy in case they want to modify
> something, we can't tell. I actually don't know if the ejb 2 beans can
> store state outside of their abstract accessors. If so, they too would
> need instance/transaction in case whey changed state. If not, at least
> conceptually copy on write is possible.
Entity bean _can_ have state besides what is saved in
ejbStore(), but: The bean cannot rely on such state
information to be saved, because what can be done in the
ejbPassivate() is quite limited (runs in an unspecified
transaction context, and may _not_ access resources).
Problem with copy-on-write is that we do not know before
the invocation returns if an invocation is a "write" (ie.
changes the state of the instance). And without the
isModified() method we do not know at all.
It would be nice if the bean provider could declare
methods as being read-only.
I guess we have two options here:
We could choose _not_ to copy before the invocation. That
means that we do not have an unmodified cached instance
ready, and that we may have to do an ejbLoad() to get one
if/when we need it. (Guess this one will not work with
snapshot isolation.)
We could choose to always copy before the invocation, and
throw away the copy if we don't need it (alternatively
save the unused copy to avoid another copy on the next
invocation).
Which one is best probably depends on the usage pattern.
> > > There is a transaction property that determines behavior when two
> > > transactions try to modify the same entity: either
> > >
> > > you get an immediate exception
> > >
> > > or
> > >
> > > your changes block until the other guy commits (you get an exception)
> > or
> > > rolls back (your transaction succeeds)
> >
> > If we should be optimistic here, I think that we should
> > get two different versions of the same entity here, each
> > with their own context associated with a different
> > transaction.
> >
> > If both are changed, the last transaction commit should
> > fail, as we might have an unresolvable update conflict.
>
> This is also possible, as soon as the first transaction commits it sets the
> other(s) Rollback Only. Throwing an immediate exception or waiting
> prevents the 2nd transaction from wasting time doing work that will be
> rolled back if the first transaction commits. It may also be easier to
> keep track of.
I do not think that we should mark the second transaction
for rollback immediately.
If the first transaction committed changed the version of
the entity that was involved with that transaction, we
should set a flag in the context of all other versions of
the same entity. The flag tells the container that any
attempt to change that version of that entity should result
in an update conflict. So if the flag is set, and an
attempt to update is made, the transaction is marked for
rollback. But if no update on the entity version is done,
the transaction it participated in can commit fine, since
we have no conflict (no need to store, and we should ignore
the other tx's update anyway due to isolation).
> > I don't think we need this strict ordering of
> > transactions.
> >
> > If we want to do optimistic transaction locking, we
> > need a cache that supports multiple versions of each
> > entity (one for each transaction that the entity is
> > participating in).
>
> Well, not necessarily, if we can manage copy on write we just need one copy
> for each different version.
>
> > If we have that, and use commit option A, we just need
> > a reference to the version last committed. However, if
> > we pick that version to use in a tx, we might need to
> > clone it, as we may need it again for yet another tx.
>
> I think this results in read committed isolation, which is kind of
> inconsistent with the idea of a transaction. Keeping track of transaction
> ordering results in much stronger snapshot isolation.
You are right: We _do_ need strict transaction ordering
for the snapshot isolation to work.
In case of single-container snapshot isolation, this could
work like you described.
But for multiple-container snapshot violation, we could
get a starters problem: In that case I think we could get
a situation where there is *no* entity version with a
transaction id <= current transaction id.
Maybe it can be done anyway; further study may be needed;
maybe copy-on-write can solve that too.
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
