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
----- Original Message -----
From: Ganesan Sankara <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Friday, May 12, 2000 7:18 AM
Subject: Design Flaw in Peer class?
> One of the basic flaws I noticed it does not support database commitment
> control. Each operation like insert,update,delete seems to getting new
> connection from pool and once done return back the control. A typical
> transaction block will include lot of tables and will be committed at the
> end once all operations are successful. This support seems to be missing
in
> Peer class?
>
> Regards
> ganesan
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
