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"
If you do C and you acquire a RO lock, this is something...
Again we don't do the "acquire" part...
|Correct, I just meant that it is irrelevant with regard to
|optimistic caches
|in an EJB container.
The pattern was not presented in that context, true. It is a simple idea on
validation of state with RO lock equivalents. Hence it's applicability
outside the initial scope.
|The "is just for read-only" is incorrect. Optimistic concurrency caches are
|useful in read-mostly usage patterns, for reasons mentioned. For read/write
|scenarios it will yield too many rollback exceptions to be useful, and
|read-only is just a special case of read-mostly.
Well a Tx lock is RO or RW, I don't know of a "RM" lock rickard. So when i
was talking of *Tx* and you started talking of ReadMostly *pattern* and
throwing "IncorrectExceptions", it sort of pissed me off.
|
|> |> So what does Option C buys us? when we start the transaction
|we do load
|> |the
|> |> state from the database... woohoo, well yes, since the state is
|> |non-valid,
|> |> however we still have the same problem I just described, which
|> |is that the
|> |> 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.
|> |
|> |Incorrect. State is valid for the duration of the transaction, which is
|why
|>
|> Incorrect (;-) how do you ensure the validation of state in time ? C
|doesn't
|> cover that Transaction Mix(at all).
|
|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.
|> |option C is necessary (option B could work too, but then you'd need to
|> |change the interface as outlined by Dan). You need to read up on locking
|> |schemes and isolation levels.
|> |
|>
|> Again, C is "necessary" (yes) but "not sufficient" how do you ensure
|> validity of state in time, where is your Tx, management. How do you know
|> once you have loaded state that it will remain valid, C doesn't say
|anything
|> about that. What we are discussing does.
|
|This is taken care of by the database. By using C one implicitly say that
|the database is left to do all the hard work of concurrency checking. The
|container is just a dumb user of the data, and doesn't have to deal with
|concurrent usage.
|
|How the database does this is somewhat irrelevant; all I care about (from a
|container developer point of view) is that it does.
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.
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.
|> |Yes, you are, but it's a somewhat long story to write in an email I'm
|> |afraid. I recommend reading the Database Fundamentals, especially
|
|Should have been "Fundamentals of Database Systems". Great book.
:) never read it :)
|Either that, or trust me on the above.
Trust is something you earn :) and you have earned "a lot" of trust, on
containers, not on Tx and DBs ;-)
|> If many instance exist and most of them exist for "read-only" transaction
|> and one entity exists for "read-write") (making the entity "read-mostly"
|:)
|> then the introduction of that kind of Tx isolation in our implementation
|is
|> trivial...
|
|Sorry, but I don't follow what you're saying.
|
|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. Lock
management isn't done at the container layer like it is done today. I was
wondering if a RO lock at the container layer wouldn't be an option to
pursue.
The reason I was "asking" instead of saying "can't we do a container lock
manager" is that I suspect it is not spec kosher.
Ok, here is where I come from, I was reading (a month ago) "Safe Locking
Policies for Dynamic Databases" by Vinay Chaudri and Vassos Hadzilacos (JCSS
1998) where they generalize the serializability proof to "insertion and
deletion of entities" and discuss 3 types of implementations for distributed
dynamic environments (READ AN EJB CONTAINER :)))). Skip the theorem on
canonical schedules, frankly I couldn't walk through it without blowing a
fuse, but the 3 policies are very interesting (Dynamic Directed Acyclic
Graph, Altruistic Locking, Dynamic Tree Policy). The paper is public and
you can find it. I got it from MIT :)
The interesting point is I believe we can come up with a "safe locking" algo
in pure distributed fashion.
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)
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.
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.
|
|Again, if you don't see this either do the background research, or
|trust me.
:)
marc
|
|regards,
| Rickard
|
|
|
|
|
