Kristian Waagan wrote:
If I were debugging this I would dump the transaction log
in the 2 cases and see if anything jumps out different. If you need
the properties for this let me know.
That would be great :)
So you need the two databases and then boot them with the following
property with a SANE build:
derby.debug.true=DumpLogOnly,LogTrace
What I am expecting now is that the one where you see no stat update
won't have the log records since they were never flushed from memory
to the file. Given your last report I think the parent transaction
is read only, so it's commit is not forcing log either. And if you
never do another write transaction after this, you are getting the
expected behavior. As I said I don't think this a problem in the
existing system as the parent transaction is never read only for
current usages of nested user read/write transactions. If in the
end you still use this then something should be done.
o could force nested user read/write commits (this is probably easiest
but will slow down some existing operations).
o could somehow mark parent transaction as not-read only when nested
user read/write xact is created.
o could provide different internal interface so that your xact could
force the write while other nested user stay as is.
