I am okay with not implementing an ejbStore() and I guess I could do the
same by maintaining an isModified variable right? We are using BMP and want
these beans to run on several app servers. I am not familiar with Commit
Option A - is this defined in the spec?
The thing that I am concerned about is that, I am seeing in most servers,
that when a method is called on an entity bean with which as the TX_REQUIRED
flag, an ejbstore and ejbload are both called.
1) Should a different flag be used?
2) Is there a way to control the database calls in ejbLoad()? I was thinking
about using the ismodified flag as away to control when the ejbload() goes
tot the database.
Any thoughts?
Thanks
>From: Rickard Öberg <[EMAIL PROTECTED]>
>Reply-To: A mailing list for Enterprise JavaBeans development
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Designing Read Only Entity Beans
>Date: Mon, 14 Aug 2000 09:02:15 +0200
>
>On Sat, 12 Aug 2000 15:46:43 GMT, Tom Jordan <[EMAIL PROTECTED]>
>wrote:
>
> >I would like to know what approaches people are taking to design entity
> >beans so that they behave in a read only manner and are sharable across
> >users. I am really interested in a portable design not BEAs read only
> >beans.
> >
> >For example, if you have a catalog of products, ideally I would like to
> >populate a bean with a product once and all subsequent users of the bean
> >would access that instance and not have to repopulate or go to the
>database
> >each time. In my use so far, I notice that every call to the beans
>methods
> >results in the ejbload and ejbstore methods being called, making the
> >operation very expensive in terms of database calls.
> >
> >any thoughts?
>
>If you go with a server that has a read-only flag for CMP, that should
>work for you.
>
>The safest bet, however, is to use BMP and simply don't implement
>ejbSave. So, it wont matter how many times the server invokes ejbSave;
>you won't go to the DB anyway.
>
>Then there's the issue of ejbLoad. If you choose a server that allows
>you to use any EJB-spec commit option, simply choose option A (state is
>valid on tx commit). If you don't have that possibility, well, there's
>not alot you can do :-(
>
>So:
>* Don't implement ejbSave
>* Choose a server that allows you to use commit option A (most servers
>*should* allow this)
>
>I could do a jBoss plug here, saying that we support read-only CMP
>beans, and blah blah this feature that feature, but you already guessed
>that, right? ;-)
>
>Oh, and the discussion some week ago on synched clustered caching of
>EntityBeans: the kind of usage you have here would work very well with
>that, but it would not only work very well for read-only, but also
>read-mostly (if you have occasional changes).
>
>/Rickard
>
>--
>Rickard Öberg
>
>Email: [EMAIL PROTECTED]
>http://www.telkel.com
>http://www.jboss.org
>http://www.dreambean.com
>
>===========================================================================
>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".
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
===========================================================================
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".
