db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Transaction contexts and log flushing
Date Fri, 06 Aug 2010 15:46:21 GMT
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.

Mime
View raw message