> |> 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.
Correct, I just meant that it is irrelevant with regard to optimistic caches
in an EJB container.
> |> 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.
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.
> |> 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.
> |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.
> |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.
> |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...
No, just not really in the mood to explain this. IMHO you are missing some
fundamentals of what a EJB container cache implementing optimistic
concurrency scheme must do. I think that the only way to get a good
understanding of what our job is, is to read up on the background theory.
Either that, or trust me on the above.
> 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).
We already have read-only support (i.e. never call ejbStore).
> 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.
Again, if you don't see this either do the background research, or trust me.
regards,
Rickard
