|> 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
|
|
|
|
|
|
|
