Hi Marc,
Here's my take on this (but I'm not a database expert). We all
agree that commit option B or C is valuable when the data could
change underneath the entity. Commit option C is also valuable
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.
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
every transaction, it would be better to serialize access to the
entity state (even with option C). 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. 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). Another way is to obtain the data within a
transaction, which will give you a read lock on the data. When you
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
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
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
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
> |
> |
> |
> |
> |
> |
> |
>
>
