see >>
> -----Original Message-----
> From: Ian McCallion [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, June 16, 1999 7:34 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Using collection bean to represent a list of entity
> beans- was RE : Application Server container related question
>
<snip>
> One way to do this, using the shopping basket example again, is as
> follows:
>
> * Design the application so that a shopping basket,
> including all items in the basket, is an Entity Bean,
>
>> one of many options is to use a collection (or whatever) for the
items. these will serialize into a blob (byte[]) in the pstore.
> * Within EJBLoad, instantiate the Basket Entity Bean by
> an SQL call on the "Baskets" table to load information
> about the basket, and an SQL call on the "Items" table
> to load all items in the basket.
>
>> if you use blob for "item" storage, you can use CMP as well as
BMP and simply deserialize/serialize the objects in ejbLoad/ejbStore. only
one call to the pstore loads the entire basket. i haven't run across
anything that persists as quickly as a byte stream.
> * as processing of the basket within the transaction
> proceeds, load the individual items into simple objects
> (we could call them sub-entity beans) as needed and
> maintain a "write-back list".
>
>> with the collection, there's no need to maintain a special list.
if the basket is dirty, the items serialize and persist on one call in
ejbStore.
> * Within EJBStore write back the state of objects in the
> "write-back list" to the database.
>
>> no need to do this. CMP does it for you by including the items
column to the list of CMP attributes. if you're BMP, you just add a single
attribute to the update statement to persist all items.
> Yes I know this can't be done with CMP,
>
>> CMP works perfectly with collections (or maps or any other
serializable structure).
> and I know that it embeds some
> messy details of persistence into the methods on the bean, but its the
> only
> way, within the EJB framework, that I can see to solve some real problems.
>
>> i'm not sure we addressed the original question, which seemed to
be more related to the issues surrounding when to use references and when to
use copies of data on the client. in any case, this is a worthwhile
discussion.
> <soapbox>
>
> If you'll allow me to use your question as an excuse for drawing together
> a
> number of threads on the mailling list, I'd say that:
>
> 1. Agressive local optimisation of inter-bean calls
> that violates the EJB spec (as done by Weblogic)
>
>> if you mean optimization of intra-vm calls, this is done to
address the cost of out-of-process calls. WebLogic has stated publicly that
they are changing their server to be RMI (EJB) compliant but will continue
to allow intra-vm optimization as an option.
> 2. Smart Proxies (as per Rickard Oberg's package)
>
>> Proxy says most of what this addresses. On top of that, "Smart"
addresses reliability issues of network activity in general and remote
computing in specific.
> 3. Anticipatory loading of entity beans (not sure
> who claimed to do this - I think it was Gemstone)
>
>> this addresses latency between ejb server and pstore. Chris Raber
can cover the details and correct me if i'm wrong.
> 4. My hack above
>
>> this addresses some of the issues surrounding very fine grained
objects.
> are all attacking different aspects of the same problem, namely the
> granularity of object models vs the granularity of architected server-side
> objects.
>
>> kind of. my interpretation is that they're addressing different
but sometimes overlapping issues related to distributed computing.
> The ideal solution, in my opinion, would be to allow every object
> in the model to be an efficiently callable CMP "sub-entity bean" and to
> compose sub-entities at deployment time into coarse-grained entity beans
> working approximately as I described above. Unfortunately "sub-entity
> beans" are not yet architected.
>
> </soapbox)
>
>> hey, wait a minute... who's soapbox is this anyway ;)
> 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".
===========================================================================
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".
