Entity CacheFullException - Weblogic

This is a discussion on Entity CacheFullException - Weblogic ; WebLogic is throwing a CacheFullException and I canít figure out why. First I do understand that entity beans in the cache cannot be passivated if they are participating in an in-flight transaction. This is my setup: 1. Every month I ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Entity CacheFullException

  1. Entity CacheFullException


    WebLogic is throwing a CacheFullException and I canít figure out why.

    First I do understand that entity beans in the cache cannot be passivated if they
    are participating in an in-flight transaction.

    This is my setup:
    1. Every month I need to refresh data in my DB2 database from a Teradata data
    warehouse. About 100000 records are fetched from Teradata and updated to two tables
    History and Element in DB2.
    2. I have two entity beans, HistoryBean() and ElementBean(), which I use to update
    the data
    3. For every History row there can be one or more Element rows (one to many).
    4. I have a session faÁade bean, TeradataServiceBean(), which controls the transaction.
    5. Transactions are container managed.
    6. Since there are so many records to update I break the updates into smaller
    transactions, 186 records at a time.
    7. The method in TeradataServiceBean() are:
    a. public void refreshDailyMetrics()throws DAOException
    b. public void refreshDailyMetrics( int month ) throws DAOException
    c. public void saveFieldValues(MinorCategory minorCategory, Calendar date, Calendar
    edate ) throws DAOException
    This method has container transaction set to Required and will start a new transaction
    when invoked.

    d. private void saveFieldValue( long fieldId, Calendar date, Calendar edate, int
    day, Long value ) throws DAOException
    e. saveFieldValue() finds and updates the data using the HistoryBean() and ElementBean()
    entity beans.
    8. All methods in HistoryBean and ElementBean have container transaction set to
    Mandatory
    9. refreshDailyMetrics calls refreshDailyMetrics( int month ) for every month
    of the year from January through to the current month (This month is December
    so I refresh data from January through to November.)
    10. refreshDailyMetrics( int month ) calls saveFieldValues(..) which in turn calls
    saveFieldValue() multiple times.
    saveFieldValues() start the container managed transaction by call saveFieldValue()
    as follows
    ( ( TeradataServiceLocal ) ( this.sessionContext.getEJBLocalObject()
    ) ).
    saveFieldValues( ( MinorCategory ) j.next(), date, edate );
    10. Max-beans-in-cache is set to 2000 and since I update 100000 records when
    Iím done 2000 beans will be in the cache.

    The refresh process works fine and all transactions are completed successfully.
    I know this because I have 53*11 (11 months) transactions and the Transactions
    Committed Total Count in the Weblogic console for the TeradataServiceBean() session
    beans shows 583=53*11 (I catch all application exceptions and invoke this.sessionContext.setRollbackOnly();
    if and application exceptions are thrown.) So after the data refresh is completed
    successfully no entity beans in the pool should be ďlockedĒ and participating
    in any transaction.

    Now for the current month we get and insert NEW data from Teradata into our database
    using the same HistoryBean() and ElementBean(). This is when BOOM I get the CacheFullException
    which I canít understand. My log file shows

    ERROR: 10 Dec 2003 17:12:17,831 com.nscorp.cd.error- javax.ejb.TransactionRolledbackLocalException:
    EJB Exception:; nested exception is: weblogic.ejb20.cache.CacheFullException

    Yes the cache I full but none of the beans in the cache are locked by any transactions.
    WebLogic should be able to use the beans in the cache to insert the new data?

    By setup is:
    1. WebLogic 7.0
    2. DB2

    Any ideas?

    Thanks

    Andrew



  2. Re: Entity CacheFullException


    Hi,

    Yes, it's true, as long as all the updates have committed and are not pending
    a
    transaction commit, then they are cached but are free to be kicked out of the
    cache to make room for new beans that are enrolling in transactions.
    So before the newly created beans are to be placed in the cache, the cache
    space should be available as all the updates had committed.
    I'm not sure that I followed the system description completely, but one thing
    that wasn't mentioned was whether the INSERTs were batched in anyway.
    Is it possible that there are too many pending INSERTs in the cache ?

    Also, which concurrency strategy is in use ? Database, Exclusive ?

    -thorick




+ Reply to Thread