Re: ACIDity of Prevayler 2.6

Rick -- Yes, what you say makes sense. It shouldn't bee too hard to
leverage the journal reading/writing code to truncate n transactions from
the end of a journal.


On Fri, Nov 16, 2012 at 8:08 AM, Rick Ross <[email protected]> wrote:

> This is perhaps slightly side topic, but …   It's been about .3 versions
> since I've done it but ACIDity was broken in another way when I tried.
>
> While loading the system with data, a memory error occurred (we had run
> out of memory).  The system was stopped and restarted.  Truly ACIDic would
> mean that the system restarts with all the data it had prior to the error
> and no other data.  The transaction that failed should not supply any
> information to the system nor should it be re-attempted automatically by
> the system.
>
> What happens in fact is that the transaction is reattempted automatically
> and fails again and again unless you make a change.  At the time, the
> solution was to try to manually delete the serialized transaction before
> restarting, but the transactions were bundled up together and really pretty
> much inseparable on disk.
>
> Like a broken record, I will say again that if the serialized transactions
> could be managed, the system could do undo style functionality out of the
> box, at least at desktop scales.
>
> R

------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

_______________________________________________
To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion
_______________________________________________
"Databases in Memoriam" -- http://www.prevayler.org