Sorry about using "Design Flaw". I agree that it is implementation detail.
Your suggestion should
work perfectly. I was already thinking along this path. Since I did not know
much history on this implementation details
I wrote this mail. Now I know why connection is not passed. I believe to
make peer work for Transaction based system
someone has to make time to do this change.
Thanks for the reply
Ganesan
>Subject: Re: Design Flaw in Peer class?
>From: "John McNally" <[EMAIL PROTECTED]>
>Date: Fri, 12 May 2000 09:01:38 -0700
>Flaw seems a bit harsh. I would say it is a feature that is easily added
>once someone has a need for it and they are willing to contribute some time
>and effort to implemement it.
>One of the goals of BasePeer is to free the developer from having to get db
>connections and return them. It is of course not very difficult, but
>leaving a connection open is a common error.
>It seems easy to me, but maybe I am missing a detail? Just rewrite things
>like:
public static void doUpdate( Criteria criteria)
throws Exception
{
DBConnection db = null;
try
{
// get a connection to the db
db = DBBroker.getInstance().getConnection();
Connection connection = db.getConnection();
doTransactionUpdate(connection, criteria);
}
finally
{
DBBroker.getInstance().releaseConnection(db);
}
}
>and move most of the code from doUpdate to doTransactionUpdate. In your
>situation you just duplicate the code found in the new doUpdate with
>auto-commit turned off and of course include the other calls required by
the
>transaction.
>Why would this not work?
>John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
