You are viewing a plain text version of this content. The canonical link for it is here.

Posted to torque-user@db.apache.org by Jim Caserta <sm...@yahoo.com> on 2006/04/10 15:27:37 UTC

RE: Torque Connection pool .. ORA- 01453 - Set Transaction must be the first statement

Thomas,

I was reading through this thread and I wantwed to be
sure what you are saying. Is the example below the way
we should be handling transactions? Thanks!


Connection dbConn = null;
try {
		dbConn = Transaction.begin(db2.torque.environment));

		////Do Stuff
		//Commit the transaction (Transaction.commit, should
release connection back to the pool
		Transaction.commit(dbConn);
		Transaction.safeRollback(dbConn);
	}catch(TorqueException e){
		try {
			Transaction.rollback(dbConn);
		} catch (TorqueException e1) {
			Transaction.safeRollback(dbConn);
		}
		}finally {
			if(!dbConn.isClosed()){
				Torque.closeConnection(dbConn);
			}
		}


--- Thomas Fischer <tf...@apache.org> wrote:

> Using commits/rollbacks without explicitly startung
> a connection may look 
> unclean but does not cause any problems in practice
> (at least none known 
> to me). The problem described seems to be the other
> way round: there is no 
> rollback/commit where should be one.
> 
>    Thomas
> 
> On Mon, 27 Mar 2006, Greg Monroe wrote:
> 
> > I did a quick wander thru the Torque code and saw
> one thing
> > that did not look right to me.  Here's some
> background first:
> >
> > All of the Torque Transaction handling is built on
> the
> > Transaction class. This is used primarily by the
> BasePeer
> > methods like doUpdate(Criteria) and the like.
> >
> > These methods are the ones that automatically wrap
> the
> > DB actions as a transaction with rollback.
> >
> > The first thing that didn't look right to me was
> that the
> > Transaction.beginOptional(dbName, useTransaction)
> method
> > is called with the useTransaction arg set to the
> value of
> > criteria.isUseTransation().  This value is set to
> false by
> > default.
> >
> > So, it seems that if you don't set this explicitly
> on your
> > Criteria, you are not using really using
> transactions but
> > you still have the Transaction try/catch code with
> commits and
> > rollbacks.
> >
> > Shouldn't the default for isUseTransactions() be
> true and/or
> > the code handle the false condition without
> calling the
> > extra transaction methods?
> >
> >
> >> -----Original Message-----
> >> From: vivek sar [mailto:vivextra@gmail.com]
> >> Sent: Saturday, March 25, 2006 4:44 AM
> >>
> >> Thanks Thomas for detailed explanation. I haven't
> dig into
> >> the Torque or dbcp code to tell exactly where the
> fault lies.
> >> The way I understand is that the db starts the
> transaction on
> >> your behalf if you don't start one. In case that
> transaction
> >> fails it will try to rollback. The problem I've
> stated is
> >> while the transaction is rolling back the same
> connection is
> >> somehow being used by other query and that's
> causing the
> >> "ORA-01453" and hanging of the connection.
> >>
> >>  I would think it's a problem with dbcp if not
> torque as dbcp
> >> is the one that handles the connection pool. I
> couldn't find
> >> much on the dbcp commons mailing-archiving list,
> but found
> >> tons of similar problems reported by torque
> users, so I think
> >> most of the people do assume it's a Torque
> problem or
> >> somewhere related to it.
> >>
> >>  Yes, if I do handle the transaction myself I
> don't get into
> >> this issue, but still the connection pool should
> handle the
> >> transactions/connections gracefully if it's
> starting one on
> >> your behalf.
> >>
> >>  I've the autocommit turned on (by default), so
> it shouldn't
> >> be problem with that either.
> >>
> >> I am still waiting for the right answer where
> exactly the
> >> problem lies -
> >> 1) How do I get ORA-01453 if I am not starting
> the transaction myself
> >> 2) Why the connection hangs after the ORA-01453
> >>
> >> Thanks,
> >> -vivek
> >>
> >
> > Duke CE Privacy Statement
> > Please be advised that this e-mail and any files
> transmitted with it are confidential communication
> or may otherwise be privileged or confidential and
> are intended solely for the individual or entity to
> whom they are addressed.  If you are not the
> intended recipient you may not rely on the contents
> of this email or any attachments, and we ask that
> you  please not read, copy or retransmit this
> communication, but reply to the sender and destroy
> the email, its contents, and all copies thereof
> immediately.  Any unauthorized dissemination,
> distribution or copying of this communication is
> strictly prohibited.
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> torque-user-unsubscribe@db.apache.org
> > For additional commands, e-mail:
> torque-user-help@db.apache.org
> >
> >
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail:
> torque-user-help@db.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org