I would have expected that around line 175 I would get the row count
as it was before the uncommitted
transaction started and that no lock would be needed to just read.

Unfortunately, Derby doesn't currently implement these "snapshot isolation"
types of semantics.

Is this the way it is supposed to work? If so, is there some
configuration parameters that I can set up
to get the behavior I expected?

You can try using a lower isolation level:
http://db.apache.org/derby/docs/10.9/devguide/cdevconcepts15366.html

But that's not exactly the same thing (e.g., at a lower isolation level,
it might be that the count returns the instantaneous count of rows
in the table, including some rows from uncommitted transactions).

thanks,

bryan


Reply via email to