Re: transaction management (RE: cvs commit:jakarta-turbine-torque NO TES)

[Jason van Zyl <jv...@zenplex.com>]

On 10/31/01 12:59 PM, "Ilia Iourovitski" <ii...@ydyn.com> wrote:

> Well, in the Ambler's design at least three classes has
> (save/retrive/delete) methods :
> PersistenceBroker, PersistenceObject, PersistenceTransaction.
> Will Torque have all of them?

remains to be seen, someone donated some code that is based on ambler's
design and I've worked on them a bit but haven't touched them for a while. I
would rather try to merge more of ambler's design into torque. I honestly
don't feel like rewriting anything because torque is very functional even
though I think it needs a lot of work. Code and docs.
 
> Thanks
> 
> Ilia
> 
> 
> 
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@zenplex.com]
> Sent: Wednesday, October 31, 2001 7:44 AM
> To: Turbine Developers List
> Subject: Re: transaction management (RE: cvs
> commit:jakarta-turbine-torque NO TES)
> 
> 
> On 10/31/01 10:19 AM, "Fedor Karpelevitch" <fe...@Barra.COM>
> wrote:
> 
>> I understand Jason's point. However I believe we still need
>> save(DBConnection) (or replacement) type of methods.
> 
> Sure, it's required now because we haven't implemented a replacement or
> redesigned it but the interface an OM object adheres to should be as simple
> as possible. Do we really need more than save()/update()/delete()?
> 
>> The reason is that
>> these allow to do multiple operations in one transaction. And transaction
>> does not necessarily means db transaction - it may be JTA transaction or
>> something else.
> 
> Sure, again I think that Ambler's work covers this well. As your persistence
> store may be something other than a database. You definitely want some
> safety in writing to an XML store that may be located on a network somewhere
> or whatever.
> 
>> So solution I see is to have an interface (call it
>> Transaction for example) which DBConnection (and possibly others would
>> implement. I hope save(Transaction) sounds better to you? Of course an
>> object would only be able to use a specific implementation of Transaction
> by
>> downcasting it.
> 
> If it's at all possible I would like just save() and have the info about the
> object's store location and the type of transaction required to save it
> somewhere else. I would like to bend torque closer to Ambler's design but I
> think he does have save(Transaction) in there somewhere if I remember
> correctly.
> 
>> As far as Byron's suggestion goes, problem with it is that in some cases
>> this may be what you want, but not always. For example you may want to use
>> several connections in the same thread at the same time. So this does not
>> work as a general solution, but can be an option if there is a reasonable
>> way to make it that way...
>> 
>> fedor.
> 
> 
> --
> 
> jvz.
> 
> Jason van Zyl
> 
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
> 
> 
> 
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>