On Feb 11, 2009, at 6:10 AM, Bert Huijben wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: woensdag 11 februari 2009 11:54
>> To: Bert Huijben
>> Cc: hyrum_wright_at_mail.utexas.edu; dev_at_subversion.tigris.org
>> Subject: Re: svn commit: r35771 - in trunk/subversion: include/
>> private
>> libsvn_fs_fs libsvn_subr
>>
>> Ugh. That would be a very hard-to-see control flow. Weird little
>> untracable side effects.
>
> In the normal flow (no errors) you would just commit or rollback; it
> would
> only add a defined rollback behavior on pool cleanup for the case
> where it
> wasn't before.
>
> I don't see how that would make things harder than your previous
> suggestions
> on moving a file on pool cleanup, etc.
>
> And in many cases you would have a sub or iterpool that has the same
> lifetime as the transaction, so I can't think of any real surprises..
>
> Just... when anything unexpected goes wrong... it would also give a
> defined
> behavior to external code that clears the apr pools on a
> SVN_ERR_MALFUNCTION_NO_RETURN() that is turned in a C++ exception or
> something.
>
>
> Crashing Visual Studio, Eclipse or anything else that might contain
> hours of
> work, on just a serf operation that receives some garbage data (or
> some
> null reference in another layer) is not an option in many cases.
>
> And I don't know what our current behavior on open sqlite sessions
> is on
> pool cleanups.
>
>
> (At first glance it looks like it just stops looking at sqlite..
> keeping
> current transactions open... and makes sqlite block other
> transactions from
> this and other processes).
The SQLite db closed on pool cleanup, which rolls back any pending
transactions. The transaction rollback is handled inside SQLite--we
don't have to do anything special.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1139120
Received on 2009-02-11 15:18:16 CET