|Here's my take on this (but I'm not a database expert). We all
none of us here is it seems :)
|agree that commit option B or C is valuable when the data could
|change underneath the entity. Commit option C is also valuable
yes
|when you don't want your transactions to block at the application
|server level while waiting for the single server instance of an entity
|component.
correct if you delegate locking to the DB. We need to do that properly
|For instance, if every order placed uses a number of product
|entities to read data but not write it, you don't want the orders
|queueing up to use the one-and-only instance of product. Instead,
|you want multiple instances of a product. However, it is still
|possible to change the product entity. This is the pattern that
|Rickard is referring to by "read-mostly." If we were modifying it with
It is a "pattern". You build a RM pattern from RO and RW locks (building
blocks).
|every transaction, it would be better to serialize access to the
|entity state (even with option C).
Yes, if we can't control that RO lock then they are all RW and the
serializability we have now is as good as it gets...
| Since we're not, we want to have
|multiple instances to avoid blocking at the application server level.
|
|Now, how do the various entities interact? We "defer concurrency
|control to the database," as mentioned--but not described--in the
|specification. The exact scheme we use to do this can vary.
Yes, this is not done in our container today.
|One way is to obtain a write lock on the database tables every time we
|use the entity (e.g. select for update). This isn't very good, because
|we will probably still end up blocking other readers during a read-
|only transaction, only at the database level (although this depends
|on the isolation level).
Well isolation level will help, I don't think we use them correctly.
| Another way is to obtain the data within a
|transaction, which will give you a read lock on the data. When you
Yes, that is the RO deferring to the DB....
I sort of believe there is an interesting RO policy at the container as
well. It won't cover the "direct DB access" but will speed up the container
level... see my previous mail.
|try to write the data within the same transaction, it will attempt to
|promote the read lock to a write lock. This has the disadvantage of
|potentially causing deadlocks. Finally, you can use optimistic
Yes, deadlock detection is the crux of good distributed DBs... I am not sure
we want to go all the way there. Remember our "80% good enough" policy for
open source.
|concurrency control by reading the data outside of the transaction
|and re-reading it in the transaction before writing it--first validating
|that it has not been changed. You can use a token (e.g. last
|modified number or date) to do this, although a more general
:))) this is pretty much the "pattern from the server side".
dum daa da dei do do
|solution is to check that no values have changed in the "where"
|clause of your second select statement. Note that the exact
|behavior of these locking mechanisms depends on the isolation
|level and the database strategy to implement it.
|
|-Dan
|
|P.S. In my opinion, commit option C is not "band-aid," but is the
|most generally useful solution. Option A is useful when the cost of
when I say band-aid I mean "necessary" yet "not sufficient" (a band aid ;-).
You need the proper locking at the db/container layer as you point out. The
strategy I don't think we have it yet, I don't know we really need it now
(the point is *now*). I was reading up on Locking strategies out of
intellectual interest and because I like to keep informed of what
fundamental research is going on in our field. I don't think we are ready
to fully implement the complexities yet and we have other priorities (yeah
clustering, the simple ones) so let the thread die, it's a Sunday morning
for gadsake.
marc
|synchronizing to one entity instance is lower than the cost of
|retrieving the data from the database cache. Option B is a highly
|special-purpose option for circumstances when you have non-
|database resources associated with a particular entity identity, that
|would be costly to reaquire.
|
|
|On 18 Nov 00, at 9:49, marc fleury wrote:
|
|> |> so how would we do it? I assume for now we are looking for a
|way to have
|> |> *several* instances in a server involved in different transactions but
|> |> reflecting the same identity in the database.
|> |
|> |Correct, as outlined in the EJB spec.
|> |
|> |
|> |> The
|> |> pattern from theserverside where you keep a index of the
|> |"update" that can
|> |> make sure you have concurrent (and long running) transactions
|on the same
|> |> entity, would be a way to do it properly.
|> |
|> |No, that is completely different.
|>
|> Incorrect, it enables validation of state from an entity over
|time . I.e.
|> validation of state at begin and end. Long running Tx implies several Tx
|> updating state.
|>
|>
|> |> so having the several
|> |> transactions in the first place is just for "read-only",
|otherwise the rw
|> |> stuff is equivalent to what we have today (and at least our
|stuff doesn't
|> |> throw exceptions allover the place).
|> |
|> |Incorrect. It is for read-mostly, and gives the two features
|> |outlined above.
|> |AFAICT these are very important features for a lot of people.
|>
|> What is incorrect? read-only vs read-mostly? read-only is at
|the Tx layer
|> (A tx is read only or not) the "read-mostly" is a "pattern of
|usage", it's
|> not a Tx, it's a Read-Mostly entity, apples and oranges Rickard.
|>
|>
|> |> 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).
|>
|> |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.
|>
|> |> In clear opC is "band-aid", the key is in lock management in
|distributed
|> |> objects, we should read the research there, so little time ...
|> |>
|> |> Maybe I am missing something?
|> |
|> |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
|> |on locking
|> |and tx isolation. I don't think anything short of that will give
|> |you a clear
|> |picture of why this is necessary for a lot of cases.
|>
|> mmmmmmmmm :) Rickard posturing imho...
|>
|>
|> Ok here is what I think... why do we not cover a "read-only" Tx.
| We already
|> implement equivalents with the "get" trick and other tricks that
|enable us
|> to do "isModified" and "tunedUpdates" but the truth is that we are rather
|> blind with the spec as to when we trigger a "ejbStore" on an instance (we
|> always do and we see inside what goes on).
|>
|> 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...
|>
|> comments?
|>
|> marc
|>
|> |
|> |regards,
|> | Rickard
|> |
|> |
|> |
|> |
|> |
|> |
|> |
|>
|>
|
|
|
|
