from what i know your colleagues are right
the commit is the call to say "confirm the statement to be written" and the flushed to the transaction log is physicaly write it on disk or maybe to the actual db write delay usually works like this 1) the user calls commit ( the method call *not* writing on the disk) 2) changes are added into an in memory queue as the buffer 3) if the oldest or the first object in the queue is older than or equal to miliseconds 4) if #3 is yes it physicaly write everything inside the queue 5) if #3 is no then it just waits after adding the changes to the in memory queue of course though im not sure if the transaction log ibeing said is the actual db or just the log itsefl but the use of transaction log is comparable to a backup or what was done per transaction that may help to replay or recover Note: usually while the changes is in memory queue it isnt written to disk and posibly not really persisted so the changes between the time periods of commit and flushing/writing to disk the changes can be lost if the database crash or ubnormal shutdown ( the transaction log if written can help recover the changes ) so having a very long time on the write delay have risk -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/h2-database?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
