marc fleury wrote:
> What I am saying is that Option C, just says "trigger ejbLoad" and then
> says "defer Tx management to DB".
>
> The "read-only" Tx isn't really implemented in our container and that would
> help.
>
> If you do C and you acquire a RW lock, you really haven't done anything
> "optimistic"
Except if the database uses a optimistic concurrency scheme there is no
locking, hence the system as a whole *is* optimistic with regard to
concurrency. AFAIK Oracle is one such database where that would work. If
the database uses pessimistic concurrency control, then of course there
is no gain.
> |The database makes sure that if two concurrent transactions write to the
> |same data, one of them will rollback to ensure data consistency. It
> |typically does this be employing timestamps.
>
> see my point in quoted parts. "State loaded is potentially invalid as soon
> as loading is done. For it not to be the case we need to lock the DB or use
> the pattern above". C needs the help from the DB right now. Tx management
> is fully at the DB level... "deferred to DB in the spec". Right now our
> container does Tx management at the container level.
No, if the database supports transactions the state is not invalid *for
the duration of the transaction*. Otherwise the C in ACID wouldn't hold.
But yes, the scheme we are describing would be deferring all the
concurrency management to the database.
> Today our container implementation is based on container control of the
> Transaction and state lock. We do not lock a record (RO or RW or whatever)
> in DB as we work on the state of an object. It's in cache. Today there is
> no unification of state management and locking policies with cache and db.
Correct, and this is something that one wants to avoid in certain
situations.
> For us to do db locking we would need to work on the container, "Option C is
> all you need" is a false statement. You need the DB and you need locks on
> the DB, no logic today.
AFAICT this is not true. If one does ejbLoad on tx begin, is that not
equivalent to doing a "select for update"? We touch the state in the db,
and if there are transactions involved the state should be invalid for
the duration of the transactions? I realize that this is dependent on
isolation levels, but for READ_COMMITED it should definitely hold (and
AFAIK this is what Oracle supports, for example).
Why is it not sufficient to touch the data on ejbLoad to know that it
will be valid for the duration of the tx?
> |All we have to do is make the optimistic key as you outlined (hash on
> |tx+real key), and mandate that option C is used as commit option. That is
> |all you need.
>
> Right now we still need to defer the Tx control to the specific DBs.
And by doing ejbLoad on tx begin that is what we'd do AFAICT.
> Lock
> management isn't done at the container layer like it is done today.
Note that with optimistic concurrency control there is no such thing as
locking. You never acquire a "lock" anywhere (i.e. you never hold on to
a resource that someone would be waiting for).
See EJB-INTEREST archives for a huuuuge discussion on this a couple
months back (archives.java.sun.com).
> So just to put it in perspective.
> We are discussing the implementation of these policies:
> The implementation
> 1- is not prevented by our cache interface (initial point)
It is if we want to do explicit transaction context usage, as is done in
the rest of the container.
> 2- is a container issue and not in ours yet, implementation wise
> 3- no, Add Option C and run isn't going to cut it. Lock management is
> mostly at the container level.
Please explain why. You have not said why doing ejbLoad at tx begin
isn't going to cut it. AFAICT it does (if some db-expert could say yes
or no on this I'd be most happy).
> 4- I believe we can implement a container level RO locking policy. The RO
> tx declaration in XML and implementation at the "container level" is
> something that I find interesting.
If I understand what you are talking about you want to preserve the "one
key, one instance" scheme from the pessimistic concurrency control we
have now, right? And do a kind of RO locking based on that? That would
be completely spec-illegal (reentrancy).
Before we go any further on this you *must* explain why doing ejbLoad
(i.e. issuing a "select * from foo where key=bar" for an entity) on tx
begin is not sufficient. *If* that is sufficient then a correct
implementation of optimistic concurrency control is indeed to a) make a
key on id+tx b) use commit option c.
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
