With entity beans, the datasource behind the bean is an consistent
abstraction, whether relational or OODB or whatever. At the end of the day,
the entity bean's state is synchronized with the datasource with ACID
transaction properties.
You can think in terms of each bean having its own copy of state which is
synchronized at transaction boundaries. Some EJB containers do work this
way. EJB vendors have license to implement this various ways though
(multiple copies or synchronization through a single bean). In any event,
the logical model is the same, although the actual implementation may have
implications on performance and scalability of your application, depending
on its read vs. write profile.
Regards,
-Chris.
> -----Original Message-----
> From: ChinMing Kuo [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, February 04, 2000 1:02 PM
> To: [EMAIL PROTECTED]
> Subject: Entity bean question: Multiple instance
>
> I'm new to EJB. After spending about a week reading through the spec and
> scanning through the archive (great forum!), there're still some nagging
> questions.
>
> I had some experience (a while back) with OODB (Poet and Versant) and then
> on the efforts of persistence Java. Other than the 'beans' aspect, the
> notion of separating the persistence storage implementation from
> domain/business logic is similar in OODB and EJB. Specifically, an entity
> bean representing a persistent object (or row if you're purely relational)
> is instantiated by some finder methods and brought to live in the
> container, much the same way as being 'chased' through pointer in OODB.
> Subsequent get/set of attributes (by the holder of the object in OODB
> terms, or by the bean clients in EJB terms) are done through method
> invocation, without worrying about transaction, just as if the in-core
> object is the same as on-disk/database object.
> The part that gets me is that I've seen references (in both books and
> here) of the same entity bean (of, say record A) can have multiple
> instances (all are record A, not record A, B, C, etc) referenced by
> multiple clients. But I have seen no examples of such to illustrate the
> scenarios where having multiple instances of the same bean are desirable.
>
> I can think of the reason where single instance can be a synchronization
> bottleneck, but what's the proper programming model for multiple instances
> of the same bean? Shall I think of it the same OODB terms and assume every
> client is holding the only copy in memory and it's ALWAYS the same as the
> one on disk, and let the container worries about maintaining consistence
> among all the instances of the same bean?
> Is this flexibility in EJB (compared to OODB or persistent Java) purely
> for performance optimization?
>
> ==========================================================================
> =
> 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".
