[Dev] Shared transactions

[Leo Bayer]

I'm not saying always use the reference counting.  But in those cases 
where we are explicitly 'or join'-ing it is implicitly what is happening 
but in the 'or join' scenario you have to conditionally commit.  Maybe 
just adding a method like "commitOrLetGuyWhoOwnsItDoIt()" on the elf 
would make me feel better.  It would be more symmetrical to the 
beginOrJoin() method.  Also, the extra three lines of code that the if 
statement requires make me feel uneasy.

 - Leo

Brett Wooldridge wrote:
> I know it seems like an obvious pattern to use (reference counting) and
> slightly simpler than what we have (only slightly), but it has some inherent
> flaws which is why JTA (and no transaction manager that I'm aware of)
> employs it.  Imagine how easy (code-wise) it would have been for JTA to
> embed reference counting in the UserTransaction object.
>
> The first issue is that the transaction may not be initiated by our code.
> It could, for example, be initiated inside of Quartz (which has the ability
> to run jobs as transactions) or some other third-party library.  Or Bundles
> from our codebase could ultimately be run inside of an application server
> such has JBoss which itself is managing the transaction boundaries.
>
> A reference counting model could also interfere with Distributed
> Transactions which are supported by JTA.  I wouldn't want to close the door
> on ZipTie in the future deploying in a multiple-server model and possibly
> needing distributed transactions between physical machines (
> http://archive.devx.com/java/free/articles/dd_jta/jta-1.asp).
>
> Lastly, two minor nits I would have with a reference counting pattern
> (besides those above) is that 1) it would elevate the Elf to being a
> Manager, because now it becomes stateful in tracking threads->counters, and
> 2) I don't like that when debugging and "stepping over" a commit() you don't
> really know if that was THE commit or just a dummy commit().  Meaning an
> explicit call to commit() from application code is not an explict commit of
> the transaction.
>
> -Brett
>
> On 8/27/07 4:01 PM, "Leo Bayer" <lbayer at alterpoint.com> wrote:
>
>   
>> Brett,
>>   Instead of doing a beginOrJoin for transactions would it make sense to
>> use some sort of "re-entrant" transaction.  Doing so would allow the
>> usage of a transaction to not care if it is the owner or not and would
>> call commit with the assumption that the last commit in the stack
>> performs the actual commit.
>>
>> For example:
>>   begin(); // begins the transaction
>>      begin(); // increments the begin count, does not begin a new
>> transaction
>>      commit(); // decrements begin count, does not commit
>>   commit(); // performs the commit
>>
>> Just a thought,
>>  - Leo
>>
>> _______________________________________________
>> Dev mailing list
>> Dev at ziptie.org
>> http://mailman.ziptie.org/listinfo/dev
>>
>>     
>
> _______________________________________________
> Dev mailing list
> Dev at ziptie.org
> http://mailman.ziptie.org/listinfo/dev
>