Chris,
You said:
> -----Original Message-----
> From: Chris Brown [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, June 14, 2000 8:54 AM
> To: [EMAIL PROTECTED]
> Subject: Re: ejbStore on accessor method
>
> Thanks for your feedback. I am in the process of designing the EJB
> infrastructure, and I believe I am coming up with common issues that most
> developers have faced. Is there a EJB design newsgroup?
>
This is a good place to discuss design issues. You can also check out
www.javasuccess.com (see the j2ee design forum) and TheServerSide.com...
There is also beans discussion list on usenet, but that has a lot of regular
bean (vs EJBean) posts on it.
> Currently, I am only using entity beans. I have taken advantage of the
> read-only setting in the optimizations section in WL. However, we have
> not
> reached a final decision on an app server yet, so I am weary to rely on
> any
> specific product features.
>
Understood. The fact that you are current only using entity bean explains
the transtaction and ejbStore behavior you mentioned. There is also the
"isModified" feature that many EJB server support. This keeps ejbStore from
being called unless the bean indicates that it has changed. (GemStone/J has
this too).
If you want to do this in a non-proprietary manner, you can implement your
own isModified technique, and just check the flag in your ejbStore method
yourself.
> I have been reading alot about design patterns in EJB, particularly the
> Session wraps Entity model which I will be using. My clients will be
> calling a "helper" stateless session bean that will utilize my entity
> beans
> and return a state object back to the client. By using a stateless
> session
> bean, will the entity bean be "wrapped" in the session beans transaction
> and
> thus the repeated store/load on every accessor method invocation
> eliminated?
>
Exactly.
> What transaction attribute should I specify for my entity bean - supports?
>
Supports or Required is generally the most flexible choice.
> If not, is grouping properties in to a single accessor method a better
> approach?
>
You might want to do this anyway. Typically your client is going to need
most of the state of your bean to pain a page...
The question of whether the creation of this view should be the
responsibility of the service layer (Session Bean) or the domain layer
(Entity Bean) is one of debate. We have some opinions you can check out in
our open source Developer's Guide.
> Thanks.
>
No sweat.
-Chris.
> > -----Original Message-----
> > From: Chris Raber [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 13, 2000 6:14 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: ejbStore on accessor method
> >
> > Chris,
> >
> > Were are you controlling the transaction from? If you are
> transactionless
> > it
> > may be WL's policy to treat each invocation on the bean as a transaction
> > (I
> > think EJB implementors are free to interpret this part of the spec).
> >
> > If you want all the invocations to be in a single transaction, you
> should
> > start a transaction from a higher level object (e.g. a session bean or
> > from
> > the client). Better yet, get all state you want from the bean in a
> single
> > invocation using a "by value" style call.
> >
> > We have documented this and related issues in our Developer's Guide
> > available at www.gemstone.com or www.javasuccess.com
> >
> > Regards,
> >
> > -Chris.
> >
> > > -----Original Message-----
> > > From: Chris Brown [SMTP:[EMAIL PROTECTED]]
> > > Sent: Tuesday, June 13, 2000 10:12 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: ejbStore on accessor method
> > >
> > >
> > > I am using WL 5.1.
> > >
> > > I have a BMP entity bean with a transaction attribute of supports for
> > the
> > > bean. I have noticed that for every access to my access methods
> > (getXXX)
> > > that ejbStore is being called. This seems very inefficient, can
> someone
> > > explain why?
> > >
> > > Thanks
> > >
> > >
> >
> ==========================================================================
> > > =
> > > 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".
>
> ==========================================================================
> =
> 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".
