db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: commit then read immediately
Date Wed, 18 Apr 2007 15:44:16 GMT

On Apr 18, 2007, at 3:05 AM, frederic barachant wrote:

> Hello.
> I have an application which initialises a database upon first start  
> then immediately starts using it.
> Initialisation consists in writing objects through jpa. After  
> commit is done, the program starts and reads back those data.
> Unfortunatly unless i set a slight sleep() after commit, data are  
> not read back on first launch, so it seems that there is a delay  
> between the moment when data is commited and the moment when it is  
> accessible. This is of course not acceptable for my application as  
> everything written must be immediately readable.
> Is my analysis correct?

Immediately after a commit the data should be available to another  
Derby application (including other JPA implementations). But the  
behavior can be affected by caching done by the JPA layer.

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.

> Is there a way to prevent this if it is a known behavior?

It's unlikely that this is a Derby issue.

Have you tried multiple JPA implementations?

Have you asked this same question on your JPA implementation's forum?

Good luck,

> I am using derby 10.2.2 in jdk6u1 on XP.
> Thank you.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message