Bryan Pendleton a écrit :
>> Initialisation consists in writing objects through jpa. After commit
>> is done, the program starts and reads back those data.
>
> I haven't heard of any problems involving a delay after commit in Derby
> itself. Perhaps jpa is not committing the data when you think it is, or
> perhaps your program is starting too soon?
>
The two parts of the program are executed one after the other, so there
can be no read before write and even if there would be a possibility for
the two (netbeans modules) to be swapped, it would hang. First module
starts a socket after db is initialised and second module can only get
the data through that socket. (in case you wonder why, multiple machines
can access that data, so i only implemented socket to reduce code and
hopefully problems. That access is not a bottleneck. )
I just double-double checked that there were no read access to the data
before write.
> Is this one program or two? Are there multiple threads involved? What is
> your transaction isolation level?
>
This is a netbeans module suite, database is filled during startup using
their startup hooks.
The data is accessed seconds later from the AWT thread when i try to
display them in a TreeView (thus in AWT thread, thus an other one).
Transaction is the default one, so i guess from documentation it is
/TRANSACTION_READ_COMMITTED.
/
|