"Bill Tutt" <billtut@microsoft.com> writes:
> I've had a couple of thoughts on this subject:
> 1) Linking in any additional 3rd party code into a server process is
> bad, especially one that tries to manage an ACID (aka transacted) store.
> Yes, this is abject paranoia, but there you go. :)
>
> 2) Performance really shouldn't be much of an issue for triggers because
> most triggers should be asynchronous triggers that fire after the commit
> succeeds. (The server doesn't block, and doesn't care if the trigger
> ever finishes)
>
> Remember, we're in transacted system land now. Triggers aren't part of
> our non-existant two-phase commit system. You can't run triggers while
> the transaction is outstanding. (It could abort.) One could make the
> argument for synchronous triggers before the transaction even begins,
> but that just extends the period of time that might cause other
> transactions to come in and invalidate your work....
For better or worse, Berkeley DB transactions are never visible
outside the filesystem interface. If you're using the svn_fs.h
interface, you never know that there is a two-phase, retry-based
anything going on.
Now, Subversion transactions, on the other hand, are highly visible.
They're persistent objects in the database, with names. They live
from one network connection to another. You'll even be able to browse
a transaction in progress with DAV, as a DAV `activity'. So this
seems loose enough that it would be okay to run scripting code while a
Subversion transaction was in progress.
(Greg promised me he'd worry about how transactions get cleaned up
when somebody's net connection is interrupted. This still worries
me.)
Received on Sat Oct 21 14:36:25 2006