Chip Wilson wrote:
> If EBs do not partition the object graph, then I could have two EBs
> resident in memory simultaneously, of different EB classes, and with
> different PKs, running in different transaction contexts, but whose
> underlying persistent representation is not completely disjoint. The
server
> will not be able to manage updates to this data, and the EBs will step on
> each other's changes.
I did not say that the only locking would be on the PKs of the EBs. Clearly
each object should be locked independently to avoid integrity problems.
This may sound heavy, but the alternative is to fully instantiate every
order to get a picture of the stock levels, which is even heavier.
In the olden days this sort of problem was solved by putting the database
online for order processing during the day and for stock processing (a
batch job) overnight. We may not want to do that today, but even supposing
we did time-separate order processing and stock processing we'd still like
the two applications to be built from a common object model.
Yet a third design alternative would be to have two copies of the database
which are kept in close sync via asynchronous messages.
It can't be stressed too often that EJB is a OO component instantiation
model, not an OO domain model.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
