Dave Wolf wrote:
>
> <snip>
>
> But we can see these inconsistancies in other places. For instance take
> basic entity beans. The consistancy model makes a quite sweeping assumption
> which is that the underlying data store is unchanging between load and store
> operations.
I agree this is the underlying assumption. Which is why we say (bang on and on!)
that transactions should be short and should use pessimistic locking to ensure
the underlying data store is unchanging.
> The spec does discuss the formation of diamond conditions due
> to clustering etc, but never discusses the formation of logical diamonds due
> to the underlying datastore being changed. Although there are solutions
> (optimistic locking, other solutions we are pursuing etc) this still
> presents a data corruption issue. So to prevent this, we should prevent
> stove piped access to the data store.
I don't follow the argument at all, possibly because I don't understand what you
mean by stove pipe (My definition of stove pipe is an application that is the
only means of accessing some data). But if every application uses short
transactions and pessimistic locking (not always the case for old-style
client-server applications and batch applications of course) we can have
concurrent access to data via multiple paths.
Regarding diamonds, they are problematic. If the system doesn't spot the
diamond, then there may be two independent copies of the same data being worked
upon by the application. If the system spots the diamond and ensures that only
one copy of the data is used, this violates the assumption of the programs
working on the data that their copy won't change while they are working on it.
Note that pessimistic locking "solves" the diamond problem, by preventing
diamond formation. To improve on this the system should spot diamonds so that
only one copy of the data is loaded and the application providing services on
that data should be designed to avoid any assumption that methods are called an
a particular sequence.
> If you cant get to the underlying
> data directly, no diamond can form. Now, if we prevent stove piped access
> to the data store, I can see no reason for O:R mappings, as the only access
> path to the data would be via the entities. If there is no O:R mapping then
> we can indeed store the entity in an opaque fashion, again as no one can get
> to the data except via the entities.
For some data this is a possibility. But I suspect that most customers would be
reluctant to lock up their data such that the only means of access is via an EB.
It is not the only "right" way to implement Entity Beans.
> Now if this is so, why use an RDBMS
> anyways, why not use an object database? Or, does a well designed in-memory
> entity bean implementation replace the OODBMS?
>
> These basic questions still haunt the direction of EJB and unless managed
> will lead to more issues like Jay originally posted.
Ian McCallion
Alexis Systems Limited
Romsey, UK
Tel: +44 1794 514883
Fax: +44 1794 501692
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
