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]
