You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Fedor Karpelevitch <fe...@Barra.COM> on 2001/10/31 16:19:28 UTC
transaction management (RE: cvs commit: jakarta-turbine-torque NO
TES)
I understand Jason's point. However I believe we still need
save(DBConnection) (or replacement) type of methods. 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. 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.
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.
-------------------------------
The Joy of CVS
> -----Original Message-----
> From: Byron Foster [mailto:bfoster@base2.cc]
> Sent: Tuesday, October 30, 2001 12:49 AM
> To: Turbine Developers List
> Subject: Re: cvs commit: jakarta-turbine-torque NOTES
>
>
>
> > >
> > > jvanzyl 01/10/29 18:53:41
> > >
> > > Modified: . NOTES
> > > Log:
> > > - just making some notes and observations.
> > >
> > > Revision Changes Path
> > > 1.8 +40 -0 jakarta-turbine-torque/NOTES
> > >
> > > Index: NOTES
> > >
> ===================================================================
> > > RCS file: /home/cvs/jakarta-turbine-torque/NOTES,v
> > > retrieving revision 1.7
> > > retrieving revision 1.8
> > > diff -u -r1.7 -r1.8
> > > --- NOTES 2001/10/30 02:38:23 1.7
> > > +++ NOTES 2001/10/30 02:53:41 1.8
> > > @@ -70,3 +70,43 @@
> > > so, the persistence layer should take care of everything.
> > >
> > > [JSS] YES!
> > > +
> > > +Questions
> > > +---------
> > > +
> > > +These are really just questions I'm jotting down as I
> go through
> > > +the source. Not really important that they be answered
> here, I'll
> > > +post the whole slew to the list eventually.
> > > +
> > > +o Why is there a save(DBConnection) in the BaseObject?
> > > + The objects should know nothing about databases, and
> if knowledge
> > > + of a specific database is required it should probably be in
> > > + some mapping mechanism. The BaseObject should be retrievable
> > > + from any store so the BaseObject shouldn't contain
> information
> > > + about any specific store type. XML persistence would be nice
> > > + to add with one of myriad tools that exist.
> > > +
> > > +o Same question for the the Persistent interface. Would be nice
> > > + to get rid of the DB specifics.
> > > +
>
> I wonder if it would be worth while to implement a pooling system that
> associates DB Connections with threads such that once a transaction is
> started, all interactions with the database from a single thread are
> done through a single associated connection. So code may look
> something
> like this:
>
> try
> {
> Torque.beginTransaction(); // Get connection, associate with this
> tread
> BaseFooPeer.doSelect(criteria1); // Uses associated connection
> BaseBarPeer.doDelete(criteria2); // ditto
> // .. do more torque connection operations
> Torque.commit();
> }
> catch (Exception e)
> {
> Torque.rollback();
> }
>
> The underlying Torque method calls would manage using the correct
> connection. While a connection was associated with a given thread no
> other thread would be able to use it.
>
> Byron
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> 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>
Re: transaction management (RE: cvs commit: jakarta-turbine-torque NO TES)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
>> I like save(Transaction), but it is really much like save(DBConnection).
>
> Not if we are storing objects somewhere other than a database :-)
Great point.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:
jakarta-turbine-torque NO TES)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/31/01 1:20 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@zenplex.com> writes:
>
>> 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.
>
> I like save(Transaction), but it is really much like save(DBConnection).
Not if we are storing objects somewhere other than a database :-)
> --
> 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>
Re: transaction management (RE: cvs commit: jakarta-turbine-torque NO TES)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@zenplex.com> writes:
> 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.
I like save(Transaction), but it is really much like save(DBConnection).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:jakarta-turbine-torque
NO TES)
Posted by 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>
RE: transaction management (RE: cvs commit:jakarta-turbine-torque NO TES)
Posted by Ilia Iourovitski <ii...@ydyn.com>.
Well, in the Ambler's design at least three classes has
(save/retrive/delete) methods :
PersistenceBroker, PersistenceObject, PersistenceTransaction.
Will Torque have all of them?
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>
Re: transaction management (RE: cvs commit:jakarta-turbine-torque NO TES)
Posted by Fedor Karpelevitch <fe...@home.com>.
i guess there should be setDeleted() and save()
On 31 October 2001 11:56, you wrote:
> delete() could entail deleting the information from the db, possibly
> preceded by copying the data into an archive, or it could mean save()
> preceded by setting a DELETED flag to true. Does delete() only cover
> the first part of the first way of deleting?
>
> john mcnally
>
> Jason van Zyl wrote:
> > On 10/31/01 12:16 PM, "Eric Dobbs" <er...@dobbse.net> wrote:
> > > On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
> > >> 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()?
> > >
> > > or even just save() and delete()
> >
> > yes!
> >
> > > -Eric
> > >
> > > --
> > > 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:jakarta-turbine-torque NO
TES)
Posted by John McNally <jm...@collab.net>.
delete() could entail deleting the information from the db, possibly
preceded by copying the data into an archive, or it could mean save()
preceded by setting a DELETED flag to true. Does delete() only cover
the first part of the first way of deleting?
john mcnally
Jason van Zyl wrote:
>
> On 10/31/01 12:16 PM, "Eric Dobbs" <er...@dobbse.net> wrote:
>
> >
> > On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
> >
> >> 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()?
> >
> > or even just save() and delete()
>
> yes!
>
> > -Eric
> >
> > --
> > 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:
jakarta-turbine-torque NO TES)
Posted by Jason van Zyl <jv...@zenplex.com>.
On 10/31/01 12:16 PM, "Eric Dobbs" <er...@dobbse.net> wrote:
>
> On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
>
>> 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()?
>
> or even just save() and delete()
yes!
> -Eric
>
> --
> 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>
Re: transaction management (RE: cvs commit: jakarta-turbine-torque NO TES)
Posted by Eric Dobbs <er...@dobbse.net>.
On Wednesday, October 31, 2001, at 08:44 AM, Jason van Zyl wrote:
> 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()?
or even just save() and delete()
-Eric
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: transaction management (RE: cvs commit:
jakarta-turbine-torque NO TES)
Posted by Jason van Zyl <jv...@zenplex.com>.
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>