Re: problem with concurrent access to ObjectCacheDefaultImpl

[Armin Waibel]

Hi David,
this sounds really strange.
> When we heavily read elements, it appears that the elements are put in
> cache, but sometimes:
>     - the element has a description of another element
hmm, we have a problem with the key of cached objects in OJB 1.0.1 
(ObjectCacheDefaultImpl), so if you use this could be a side-effect of 
that issue (fixed in later versions, doesn't appear in older versions AFAIK)

>     - is missing one or more description
In older versions of OJB it could happen that under heavy load partial 
materialized objects are pushed to the cache and other threads may 
lookup these objects before the materialization is finished (this should 
be fixed in 1.0.3).

> Note also that we faced this problem with WebLogic, but never (or not 
yet)
> with Jboss.

... or it's something completely different ;-)
If you are using OJB 1.0.3 you can try to use ObjectCacheTwoLevelImpl as 
an alternative if the problems happen again
http://db.apache.org/ojb/docu/guides/objectcache.html#ObjectCacheTwoLevelImpl

regards,
Armin
[EMAIL PROTECTED] wrote:
Hi Armin,
Thanks for the tip.
I will try it later.
As my workaround solves the problem, without big performance impact, we
stick to this solution for the moment...
Unfortunatly, this problem occurs also when we only read data.
It's quite difficult to reproduce, but when we heavily read data, it
happens.
Scenario:
- An element (table T_Elements (pk elementId) has descriptions in several
languages table T_Descriptions (pk elementId + langId)
- Both are cached
- T_Elements has a collection descriptions proxy=true and auto-retrieve=true
When we heavily read elements, it appears that the elements are put in
cache, but sometimes:
    - the element has a description of another element
    - is missing one or more description
Note also that we faced this problem with WebLogic, but never (or not yet)
with Jboss.
And I also noticed that with WebLogic we have unexpected behaviour with
synchronized methods/blocks.
Hope it helps to understand the problem.
David WIESZTAL.

-----Original Message-----
From: Armin Waibel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 20, 2005 8:42 PM
To: OJB Users List
Subject: Re: problem with concurrent access to ObjectCacheDefaultImpl

Hi David,
[EMAIL PROTECTED] wrote:
Hi Armin,
I'm writing an application using session beans and Ojb, and deploy on
Jboss
in development and on WebLogic in prod.
I'm facing problems with ObjectCacheDefaultImpl when the application is
heavily used in prod.
It seems that the synchronized statement in the cache does not behave
correctly, and then the objects in he cache are corrupted.
Are you aware of this problem ?

Could you describe more detailed? Does it happen after a rollback or 
does it happen on commit action too.
Which OJB version do you use, which API?


Did you face it before ?

No, but if the problems occur after a rollback the problem could be 
caused by call of PBStateListener#beforeClose, because this method was 
called twice in managed environments.


Do you have a solution ?

Please replace the following methods in ObjectCacheDefaultImpl and run 
your test again. Maybe this will solve the problem.

public void beforeRollback(PBStateEvent event)
{
     synchronizeWithTracedObjects();
     identitiesInWork.clear();
}
public void beforeCommit(PBStateEvent event)
{
     // identitiesInWork.clear();
}
public void beforeClose(PBStateEvent event)
{
     if(!broker.isInTransaction())
     {
         identitiesInWork.clear();
     }
}
public void afterCommit(PBStateEvent event)
{
     identitiesInWork.clear();
}

I've implemented the following solution:
I've implemented a new class for the cache, this class calling a session
bean (max-bean-in-free-pool = 1).
I then ensure that the synchronized access to the cache is done using the
singleton session bean.
What do you think of this solution ?
Are you interested in the code ?

If we can't fix this problem I'm seriously interested in a "workaround" 
for managed environments.

regards,
Armin

David WIESZTAL.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]