Re: Is the entity cache really a pool - Weblogic

This is a discussion on Re: Is the entity cache really a pool - Weblogic ; From: "Simon Spruzen" Sender: "Simon Spruzen" Reply-To: "Simon Spruzen" Subject: Re: Is the entity cache really a pool Newsgroups: weblogic.developer.interest.ejb.cmp X-User-Info: 194.202.49.109 References: NNTP-Posting-Host: 194.202.49.109 X-Original-NNTP-Posting-Host: 194.202.49.109 Message-ID: Date: 1 Aug 2003 08:29:05 -0700 X-Trace: newsgroups.bea.com 1059751745 194.202.49.109 (1 Aug ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Is the entity cache really a pool

  1. Re: Is the entity cache really a pool

    From: "Simon Spruzen"
    Sender: "Simon Spruzen"
    Reply-To: "Simon Spruzen"
    Subject: Re: Is the entity cache really a pool
    Newsgroups: weblogic.developer.interest.ejb.cmp
    X-User-Info: 194.202.49.109
    References: <3de1f94c@newsgroups.bea.com> <3de4ae99@newsgroups.bea.com> <3de504a1$1@newsgroups.bea.com> <3de642ee@newsgroups.bea.com> <3de64ca1$1@newsgroups.bea.com> <3de72ef9@newsgroups.bea.com>
    NNTP-Posting-Host: 194.202.49.109
    X-Original-NNTP-Posting-Host: 194.202.49.109
    Message-ID: <3f2a8741@newsgroups.bea.com>
    Date: 1 Aug 2003 08:29:05 -0700
    X-Trace: newsgroups.bea.com 1059751745 194.202.49.109 (1 Aug 2003 08:29:05 -0700)
    X-Original-Trace: 1 Aug 2003 08:29:05 -0700, 194.202.49.109
    Organization: BEA NEWS SITE
    Lines: 225
    XPident: Unknown
    Path: newsgroups.bea.com!not-for-mail
    Xref: newsgroups.bea.com weblogic.developer.interest.ejb.cmp:6147


    I've been following this thread with interest (we're on 6.1 SP2); I have some questions:

    1. if database concurrency is used, regardless whether db-is-shared is true or
    false, what's the cache used for? If data has to be reloaded on every ejbLoad()
    in this case, surely that's greated than the cost of creating a new object, so
    why the cache at all?

    2. Or is the cache purely (in this case) an in-txn cache that you would expect
    to get flushed when the txn commits?

    3. For exclusive currency, and db-is-shared=false, then the cache can be long-lived,
    as its aim it to reduce the need for bean ejbLoads().

    4. Either way the cache need to be sized to take into account the largest working
    set used in a single transaction (and the CR patch mentioned *enforces* this rule
    for SP2 and SP3)

    Is my understanding correct?

    simon.


    "Maria Salzberger" wrote:
    >
    >Don,
    >thanks for the info.
    >
    >In WLS 6.1 up to SP3 you may see more than max-beans-in-cache in your
    >cache if
    >you use database concurrency.
    >This has been addressed in CR083896 - for which a one-off patch is available
    >on
    >top of SP2 and SP3. It is fixed in SP4. If you need one of those patches,
    >please
    >open a case with support and request the patch.
    >
    >What the patch does is it limits the number of EJB instances in the cache
    >to max-beans-in-cache
    >for every single transaction. If you run your EJB-clients non-transactional
    >(each
    >create of the bean runs in its own transaction) or more than one transaction,
    >you may see more than max-beans-in-cache.
    >
    >As for the re-use of EJB instances, this is container internal. I think
    >the re-use
    >is not dependent on the former primary key of the instance as the instances
    >in
    >the free pool are anonymous. Therefore it would not know which PK was
    >formerly
    >assigned to it.
    >
    >I hope this information helps. If you have additional questions, please
    >let me
    >know.
    >
    >Kind Regards
    >Maria Salzberger
    >BEA Customer Support
    >
    >"Don Marshall" wrote:
    >>
    >>
    >>6.1sp3
    >>
    >>"Maria Salzberger" wrote:
    >>>
    >>>Don,
    >>>which version of WLS do you use?
    >>>Maria
    >>>
    >>>"Don Marshall" wrote:
    >>>>
    >>>>Hi Maria,
    >>>>
    >>>>Thanks for you reply. Your right that I'm using database concurrency.
    >>>>
    >>>>Is a bean instance in the cache only re-used if an instance with the
    >>>>same PK is
    >>>>to be loaded from the database? I've performed a separate test which
    >>>>sets a small
    >>>>max-beans-in-cache for an entity. A particular request will need more
    >>>>than that
    >>>>number to succeed. I find that many more instances of the EJB are

    >created
    >>>>than
    >>>>the value of max-beans-in-cache. At the end of the transaction, enough
    >>>>are passivated
    >>>>to put the cache count to that of max-beans-in-cache (For example

    >max-beans-in-cache
    >>>>is 5 but 12 instances are created that hold data, some others are

    >created
    >>>>that
    >>>>appear to satisfy home methods, ejbLoad is called 12 times, ejbStore
    >>>>is called
    >>>>12 times and ejbPassivate is called 7 times). Are the passivated instances
    >>>>garbage
    >>>>collected at some point?
    >>>>
    >>>>When I re-run the test, not so many instances are created. I would

    >>have
    >>>>expected
    >>>>7 instances to hold the data for the 7 passivated entities but actually
    >>>>12 extra
    >>>>ones are created.
    >>>>Are the cached instances used to load data for any of the entities

    >>or
    >>>>only those
    >>>>with exactly the same PK. If only exactly the same PK and assuming

    >>that
    >>>>re-using
    >>>>the cached instances is faster than creating ones from scratch, it

    >>would
    >>>>seem
    >>>>that the max-beans-in-cache should correspond to the number of entities
    >>>>in the
    >>>>database (memory constraints permitting). What's your view?
    >>>>
    >>>>Regards,
    >>>>
    >>>>Don
    >>>>
    >>>>"Maria Salzberger" wrote:
    >>>>>
    >>>>>Don,
    >>>>>
    >>>>>I assume that you use database concurrency for your EJBs.
    >>>>>
    >>>>>In this case ejbPassivate() is called if an EJB instance is moved

    >>from
    >>>>>the READY
    >>>>>pool (EJBs which have an identity assosiated) to the free pool.
    >>>>>
    >>>>>ejbPassivate() will store the identity information (PK) to enable

    >>ejbActivate
    >>>>>to restore the identity of the EJB instance before the EJB gets back
    >>>>>into the
    >>>>>READY pool.
    >>>>>
    >>>>>As you said, the actual EJB data is then reloaded by ejbLoad() from
    >>>>the
    >>>>>underlying
    >>>>>database.
    >>>>>
    >>>>>HTH
    >>>>>Maria Salzberger
    >>>>>BEA Customer Support
    >>>>>
    >>>>>"Don Marshall" wrote:
    >>>>>>
    >>>>>>Hi,
    >>>>>>
    >>>>>>In the documentation for WebLogic 6.1,it states that:
    >>>>>>
    >>>>>>"WebLogic Server never pools instances for entity beans. Instead,
    >>>allow
    >>>>>>WebLogic
    >>>>>>Server to create a new instance. "
    >>>>>>
    >>>>>>I set up an experiment with a simple CMP entity bean where I call
    >>>the
    >>>>>>findByPrimaryKey
    >>>>>>method a large number of times repeatedly using the same primary

    >>key.
    >>>>>>Each find
    >>>>>>occurs inside a transaction. The sequence is therefore:
    >>>>>>
    >>>>>>for (a large number)
    >>>>>> begin transaction
    >>>>>>
    >>>>>> find
    >>>>>>
    >>>>>> commit transaction
    >>>>>>
    >>>>>>end for
    >>>>>>
    >>>>>>If I set max-beans-in-cache for an entity bean, I can see that only
    >>>>>that
    >>>>>>number
    >>>>>>of bean instances are actually created (plus two more presumably

    >>to
    >>>>>satisfy
    >>>>>>home
    >>>>>>method invocations). There is a lot of passivation/activation after
    >>>>>the
    >>>>>>number
    >>>>>>of times find is called exceeds the number of beans in the cache.
    >>>The
    >>>>>>instances
    >>>>>>in the cache are being re-loaded with data from the database to

    >satisfy
    >>>>>>the new
    >>>>>>find requests. It appears to me that WebLogic is using the cache

    >>like
    >>>>>>a pool.
    >>>>>>
    >>>>>>The data that is being passivated is stale once the transaction

    >that
    >>>>>>loaded it
    >>>>>>from the database has finished. Why is it necessary to passivate

    >>the
    >>>>>>data in this
    >>>>>>situation? If a client that had a reference to an entity bean requested
    >>>>>>data from
    >>>>>>the entity bean (called a getter method) after the transaction has
    >>>>finished,
    >>>>>>the
    >>>>>>data would be re-loaded from the database anyway (the transaction
    >>>has
    >>>>>>finished
    >>>>>>so the invocation would take place in a new transaction).
    >>>>>>
    >>>>>>Any one care to comment?
    >>>>>>
    >>>>>>Regards,
    >>>>>>
    >>>>>>Don
    >>>>>>
    >>>>>>
    >>>>>
    >>>>
    >>>

    >>

    >



  2. Re: Is the entity cache really a pool

    Hi Simon,

    "Simon Spruzen" wrote in message
    news:3f2a8741@newsgroups.bea.com...
    > I've been following this thread with interest (we're on 6.1 SP2); I have

    some questions:
    >
    > 1. if database concurrency is used, regardless whether db-is-shared is

    true or
    > false, what's the cache used for? If data has to be reloaded on every

    ejbLoad()
    > in this case, surely that's greated than the cost of creating a new

    object, so
    > why the cache at all?


    This cache works during ongoing TX only.

    > 2. Or is the cache purely (in this case) an in-txn cache that you would

    expect
    > to get flushed when the txn commits?


    That's correct.

    > 3. For exclusive currency, and db-is-shared=false, then the cache can be

    long-lived,
    > as its aim it to reduce the need for bean ejbLoads().
    >
    > 4. Either way the cache need to be sized to take into account the largest

    working
    > set used in a single transaction (and the CR patch mentioned *enforces*

    this rule
    > for SP2 and SP3)


    That's right. Yet, somebody told here that there is work going to
    make cache items discardable so that there wouldn't be need to
    size cache to biggest result set, that makes a lot of sence.
    Though, there were no ETA given...


    Regards,

    Slava Imeshev



  3. Re: Is the entity cache really a pool


    Thanks for your reply - finally, can you indicate just how finders interact with
    the cache during a txn (still WLS6.1 SP2). My understanding is:

    1. a findByPrimaryKey() can check the cache to see if the key is extant, thus
    saving a db hit.

    2. a findByAnythingElse() always hits the db, and doesn't touch the cache at all.
    This means that finders won't normally see uncommitted data unless either delay-updates-until-end-of-tx
    is false, or include-updates is true (either way causing an early flush of the
    cache)

    Thanks,

    simon.


    "Slava Imeshev" wrote:
    >Hi Simon,
    >
    >"Simon Spruzen" wrote in message
    >news:3f2a8741@newsgroups.bea.com...
    >> I've been following this thread with interest (we're on 6.1 SP2); I

    >have
    >some questions:
    >>
    >> 1. if database concurrency is used, regardless whether db-is-shared

    >is
    >true or
    >> false, what's the cache used for? If data has to be reloaded on every

    >ejbLoad()
    >> in this case, surely that's greated than the cost of creating a new

    >object, so
    >> why the cache at all?

    >
    >This cache works during ongoing TX only.
    >
    >> 2. Or is the cache purely (in this case) an in-txn cache that you would

    >expect
    >> to get flushed when the txn commits?

    >
    >That's correct.
    >
    >> 3. For exclusive currency, and db-is-shared=false, then the cache can

    >be
    >long-lived,
    >> as its aim it to reduce the need for bean ejbLoads().
    >>
    >> 4. Either way the cache need to be sized to take into account the largest

    >working
    >> set used in a single transaction (and the CR patch mentioned *enforces*

    >this rule
    >> for SP2 and SP3)

    >
    >That's right. Yet, somebody told here that there is work going to
    >make cache items discardable so that there wouldn't be need to
    >size cache to biggest result set, that makes a lot of sence.
    >Though, there were no ETA given...
    >
    >
    >Regards,
    >
    >Slava Imeshev
    >
    >



+ Reply to Thread