Hi Alexander,
 Note: the problem is not that Autocommit is being set. It is that the setting 
alternates between true and false.query1 /true ,qyery2/false query3/true and so 
on......(Autocommit is set true in the URL in sapdb- service.xml but the same happens 
even if it is not). The application stalls because an insert/update query was executed 
through a jboss connection with autocommit=false and the query was not committed by 
the transaction manager causing the whole application to stall (due to other queries) 
as a row is still locked. The next query executes only when the lock time's out or the 
query itself times out.
   I do not want jboss to manage the transaction I only want it to provide a pool. I 
tried disabling the transaction manager but it seems that it is a required parameter. 
Note Have tried an equivalent service.xml file (with the same standard transaction 
manager) for both postgresql and oracle and no problems occur.
Any suggestions?
Thanks 
Ajit.

-----Original Message-----
From: Schroeder, Alexander [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, October 09, 2002 12:54 PM
To: ajit_cus
Subject: RE: Bug in sap JDBC drivers and Jboss+SAP

Hi Ajis,

>   Problem:When using a Jboss connection pool with a jboss 
> transaction manager(\java:\TransactionManager) in the xml 
> file(note this is not an optional attribute). The transaction 
> manager alternatively sets autocommit to true and false for 
> every query(note:I am using autocommit=true in my 
> app).(Tracked this by using the trace option in jdbc 
> connection string). 
Hmm. Do you want to use a connection managed and monitored by
the transaction manager with autocommit set to true by the 
application? This sounds not like a good idea. Usually, 
a connection is given by the transaction manager to you 
with autocommit off, and if your bean supports transactions
you are forbidden to call commit or rollback by yourself.

BTW - setting autocommit on and off itself 
is not an expensive operation, as this will only 
set a flag for the commands that will be sent to the database. 
The container will often call this method, just to be sure
that the mode is set correctly when the connection is given to
you. So in the trace you will see a lot of setAutocommit(xxx) 
calls. They are quite normal. 

> This causes some locks to be set and not 
> released completely slowing down SAPDB.

What kind of operations do you do, where there are locks 
remaining? Do you have some trace about these situations?
Is a deadlock detection seen somewhere in the trace? Or 
is the application freezing?

Regards

Alexander


_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general

Reply via email to