Journaling

[Ivan Smahin]

On Apr 19, 2012, at 9:21 PM, Ruslan Zasukhin wrote:

> On 4/19/12 5:03 PM, "Fabian Kneubuehl" <support at ysd.ch> wrote:
> 
> Hi Fabian,.
> 
>> That makes things a bit complicated. If I never call flush at all and the
>> user’s PC crashed at the end of the day he loses all his entries?
> 
> May be... Ivan?
> 

Yes, currently it is possible. But take into account that rollback journal is about to rolling back all "dirty" changes in the db in order to get the db in consistent state after any crashes or other abnormal events.

After Db.Flush() disk image of the database has no "dirty" changes  - so you may use this as a temporary replacement of commit procedure.


> You MUST call flushes.
> 
> As well as working with transctions you must do
>    START TRANSACTION
>    COMMIT
> 
> And sometimes even write logic for ROLLBACK.
> 

Just later, when transactions will be implemented, you will call commit instead of flush.

> 
>> Personally I would prefer a flush after each UPDATE/INSERT/DELETE as in our
>> current version but because simultaneous journaling slows down these operation
>> 10 times I should think about disabling journaling – except you can minimize
>> the overhead for both operations at the same time (flush each change and
>> journaling).
> 
> We will check yet this timing ....
> I am not sure this is right ...
> May be something should be improved ...
> 

The latest benches for different kind of insert/update/delete shows 0-15% overhead.
Could you send me some test app to see that 10-times overhead?

-- 
Best regards,
Ivan Smahin
Senior Software Engineer
Paradigma Software, Inc
Valentina - The Ultra-Fast Database
http://www.valentina-db.com