I should have mentioned that I've already added isModified() to our entity
beans; sorry. I'm seeing an ejbStore on every setXxxx call; isModified()
eliminated the ejbStore that was occurring on every getter. My previous
assumption that the container could tell gets from sets and not store was
wrong - the container has no way to tell if getters are making changes in 1.1.
I have a partially completed test that moves the bean beater from a client
to a session bean to see if the extra(?) stores are related to using a
non-transactional context client, but it's been preempted by higher
priority work.
Kirk Yarina
At 10:52 AM 9/27/00 -0600, you wrote:
>I'd also like to know a bit more about how the caching works. As for all those
>"unnecessary" database writes - I guess they're there to help ensure data
>integrity in the event of a crash... You can eliminate many of them though -
>from the FAQ:
>
>Q: I am using CMP Entity beans and call many methods on it that do not modify
>the state of the bean. How can I help Orion figure out that I am not
>changing the state and that it does not need to talk to the database?
>
>A: Implement the method "public boolean isModified()" in your bean to
>return a
>boolean flag that you set each time you modify your bean and clear in
>ejbStore(). If isModified() returns false, Orion knows that it doesn't
>need to
>talk to the database
>
>Weblogic (I think - one of the "big" appservers anyway) does the same sort of
>thing.
>
>
>-t
>
>On Wed, Sep 27, 2000 at 10:52:34AM -0400, KirkYarina wrote:
> > I'm also like to hear the answers - we're also seeing an apparent database
> > write per CMP bean reference.
> >
> > At this point our test programs (not our real application...) are clients
> > that access entity beans directly, rather than going through a session
> bean
> > facade. We've speculated that the individual database writes somehow
> > result from the direct client accesses, but we're only guessing. Changing
> > transaction attributes doesn't make any difference, and (for now) we have
> > exclusive-write-access="true" on every table.
> >
> > I have to periodically justify CMP vs BMP, not to mention Orion, and
> it's a
> > problem when I can't explain why caching doesn't seem to be working...
> >
> > Come on guys, share some details. You don't have to delve into
> proprietary
> > information, but the 5 minute overview would make life a lot easier for
> > those of us who have to justify Orion to our investors - and ourselves -
> > when it comes time to bet our business on it. We'd appreciate it.
> >
> > Kirk Yarina
> >
> > At 06:21 AM 9/27/00 -0400, you wrote:
> > >Hello everyone,
> > >
> > >This question has been asked before in this mailing list but there has
> been
> > >no answer yet. I hope that there is some response this time.
> > >
> > >The questions are:
> > >1. Does Orion implement EJB object caching? If yes, I'll appreciate some
> > >details on what has been implemented.
> > >2. I want to find out specifically about CMP based EJB caching. When are
> > >these beans cached and what evicts them from cache? I have implemented
> some
> > >CMP EJBs and I see that anytime I want to access these beans, a database
> > >call is made. To clarify, my client starts up and instantiates these beans
> > >and then exits. When I restart the client, when it accesses the same beans
> > >leads to database calls.
> > >3. Some details about session beans caching will also be appreciated. Does
> > >Orion allow that some number of session bean instances be pre-created? If
> > >yes, how can this be specified?
> > >
> > >Thanks,
> > >Deepak
> >
> >
> > Kirk Yarina
> > [EMAIL PROTECTED]
> >
>
>--
>
> Tony Abbott [EMAIL PROTECTED]
Kirk Yarina
[EMAIL PROTECTED]
