>
> 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.
What I mean by stove piped access is any access into the underlying
datastore which does not come through the EJB system. Imagine an inventory
system. We have a table which holds product ids, and their quanitities
called PRODUCTS. We now have an entity called Products which maps onto this
table. A user does a findByPrimaryKey(new Integer(1)) to find product "1".
The finder reads the quantity as say 100. The user now does a getQuantity()
which also returns 100. At this moment, someone via another system which
has direct access to the data issues a SQL update as
UPDATE PRODUCTS SET QUANTITY = 1 WHERE ID = 1;
Moments later the EJB does say setQuantity(quantityRead - 99);
Ta-Da, we have a diamond formed. Now this diamond could have been addressed
in two ways.
1) The Product bean could have issues an isolation level 3 query. The
negetive is this serializes access to the store which is likely unacceptable
or
2) During the ejbStore() operation the entity bean could have used
optimistic locking to inform the caller that the underlying data was
changed. The negetive to this is that we need to issue the query over and
over to get it right.
So stove piped access leads to the formation of diamonds not addressed by
the spec.
>
> 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.
I agree that the container can quite easily handle the formation of local
diamonds. Basically it requires the container to do an ejbLoad() for all
EJBObject instances where an ejbStore() just occured. But what I describe
above is basically a actually a diamond. And its a distributed diamond
which occurs outside the realm of any ejb container, meaning it is very hard
for the ejb container to ever resolve.
So my argument came about to say it might logically be inferred from the
spec, that to prevent such situations from occuring, we should force all
access to the RDBMS to come through the EJB system such that this form of
external diamond could not form. And if we follow this line of reasoning,
then why are we using the RDBMS at all?
>
> 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.
But are we saying that we advocate pessimistic locking at isolation level 3?
In my case above unless you ran at isolation level 3 this same external
diamond would have formed.
>
> > 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.
I agree with you, and if most customers arent happy with a single path to
their data then will they be happy with entity beans? If they are happy
with entitiy beans, why worry about what format it stored in internally,
because you cant get to it anyways. Hence the catch-22.
Heck people may say Im crazy but its better then arguing about the job
market in India.
Dave Wolf
Internet Applications Division
Sybase
>
> > 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".
>
>
===========================================================================
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".
