db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: commit then read immediately
Date Wed, 18 Apr 2007 19:16:25 GMT


frederic barachant wrote:
> Craig L Russell a écrit :
> 
>> Hi,
>>
>> Are the reader and writer in different processes? Then caching is 
>> definitely on your list of "to be investigated".
>>
>> If there's no caching, I can't think of anything that might cause this.
>>
>> Another possibility is that you are not managing relationships 
>> correctly (on both sides of the relationship). And the access pattern 
>> relies on navigating relationships instead of querying or finding 
>> instances by key.
>>
> I do not think it is the case. Remember that a simple sleep after commit 
> changes/'corrects' the behavior. No other code change is needed.
> 
>>> Is there a way to prevent this if it is a known behavior?
>>
>>
>> It's unlikely that this is a Derby issue.
> 
> That was my first guess, as no one would use it if it were the case. :)
I also can't think of any way that this can be a Derby issue.  Once 
Derby executes a change to the data we actually have no previous copy
  of the data around (we have no versioning support to get at previous
copies of the data).  This sounds like some cache in the software 
between derby and your application.
> 
>>
>> Have you tried multiple JPA implementations?
>>
> Not yet.
> 
>> Have you asked this same question on your JPA implementation's forum?
>>
> Not yet. I wanted to start at lowest level first. This will be my next 
> step.
> 
>> Good luck,
> 
> Thank you, i will need it.
> 
> 


Mime
View raw message