Hi,
(Just brainstorming here, sorry if I'm wrong.)
This algorithm may be fine, but it seems to be for commit
option A only.
I think we should also consider the other commit options,
and optimistic/pessimistic locking.
David Jencks wrote:
>
> Hi, the algorithm is in the post marc was replying to.
>
> Here it is again, with garbage collection instructions and referring to
> entities rather than records.
>
> 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.)
> Each entity (version) includes the transaction id of the last change to it.
>
> When an entity is first loaded from the db, the transaction id of the
> transaction in which it is loaded is associated with the entity version.
>
> When you find an entity (within a transaction), you get the entity
> version with the largest transaction id <= your transaction id.
I think a DB load of the entity is needed, if the entity
has not yet been loaded in that particular transaction.
You want to see uncommitted changes made from elsewhere
in the same transaction to the database representation
of the entity. (That is, if you do _not_ use commit
option A.)
> 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?
> The
> older versions hang around until no transactions are active that could see
> them, then they are garbage collected. (see below)
>
> 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.
But if one of the entities are not changed, the commit
of the transaction it is associated with needs no
database update, and that particular entity version
can be thrown away at commit time (even if other
transactions have made (and possibly committed) changes
to other versions of the same entity).
> Note that only the most recent (committed) version can be modified by any
> transaction, and that the blocking/ exception behavior just described only
> applies to 2 transactions trying to modify the most recent committed
> version.
>
> Each transaction as it starts is put on an ordered (by transaction
> sequence) list of active transactions. When it is committed or rolled
> back, it is removed. The first transaction on this list is the oldest
> active transaction.
>
> The transaction associated with the oldest entity version we have to keep
> around is the oldest interesting transaction.
>
> Lets suppose we have an entity with versions for transactions t1, t7,
> t11,...
>
> We can discard the version for t1 when the oldest active transaction is at
> least t7, because all transactions that could possibly reference that
> version have completed.
>
> Note that this results in snapshot transaction isolation rather than read
> committed. (I don't know how read committed is implemented, and don't know
> why you would want to use it). I confess I don't quite understand how
> snapshot differs from serializable isolation -- its certainly close.
>
> This requires a version for each modifying transaction, rather than a
> single version or a version for each transaction. You may need to keep
> several committed versions around at once until all transactions
> referencing them are complete.
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).
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.
> Interbase versioning is per transaction , not per query.
I think we need per-transaction versioning in the cache
too, if we should support this and/or optimistic locking.
Best Regards,
Ole Husgaard.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
