Hello,

you might want to look at LOCKSTATISTICS whether there are row locks
and the DELETE wants to have a tab exclusive lock on that table.

If a lot of rows needs to be locked, MaxDB may decided to lock
the complete table, which of course may wait if there are other 
row locks by other sessions on that table. You may increase the
MAXLOCKS database parameter, to increase the number of possible
individual row locks.

Regards

Alexander Schr�der
SAP DB, SAP Labs Berlin 

> -----Original Message-----
> From: Brett Randall [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 05, 2004 11:42 PM
> To: [EMAIL PROTECTED]
> Subject: JDBC Delete causes block-freeze on native socketread0
> 
> 
> I've been conducting some JDBC tests on the MaxDB JDBC Driver 
> (com.sap.dbtech.jdbc.DriverSapDB).  My primary test mechanism 
> is the JUnit 
> tests provided with Hibernate (www.hibernate.org).  Hibernate 
> supports the 
> SapDB SQL dialect.
> 
> My environment is:
> 
> Win2K SP4
> JDK 1.4.2
> MaxDB 7.5.0.11 / JDBC driver 7_5_01
> Hibernate 2.1
> Eclipse IDE 3.0M8
> 
> The most serious problem I encounter occurs during attempted 
> database delete 
> statements.  The symptom I experience is when a (prepared) 
> delete statement 
> is executed e.g.
> 
> delete from "glarchez" where tha_key=? and version=?
> 
> ... my application freezes waiting on a read from 
> java.net.SocketInputStream.socketread0 (native method).  All 
> the variables 
> seem OK to that point, socket FDs everything.  The stack 
> trace at the freeze 
> is:
> 
> SocketInputStream.socketRead0(FileDescriptor, byte[], int, 
> int, int) line: 
> not available [native method]
> SocketInputStream.read(byte[], int, int) line: 129
> SocketComm.receiveData() line: 536
> SocketComm.receive() line: 447
> SocketComm(JdbcCommunication).execute(StructuredMem, int) line: 44
> ConnectionSapDB.execute(RequestPacket, boolean, boolean, 
> Object, int) line: 
> 403
> ConnectionSapDB.execute(RequestPacket, Object, int) line: 349
> CallableStatementSapDB.execute(int) line: 407
> CallableStatementSapDB.execute() line: 293
> CallableStatementSapDB.executeUpdate() line: 738
> EntityPersister.delete(Serializable, Object, Object, 
> SessionImplementor) 
> line: 595
> ScheduledDeletion.execute() line: 29
> SessionImpl.executeAll(List) line: 2382
> SessionImpl.execute() line: 2340
> SessionImpl.flush() line: 2204
> FooBarTest.testCustom() line: 1536
> NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not 
> available [native method]
> NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
> DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
> Method.invoke(Object, Object[]) line: 324
> FooBarTest(TestCase).runTest() line: 154
> FooBarTest(TestCase).runTest() line: 82
> FooBarTest(TestCase).runBare() line: 127
> TestResult$1.protect() line: 106
> TestResult.runProtected(Test, Protectable) line: 124
> TestResult.run(TestCase) line: 109
> FooBarTest(TestCase).run(TestResult) line: 118
> TestSuite.runTest(Test, TestResult) line: 208
> TestSuite.run(TestResult) line: 203
> RemoteTestRunner.runTests(String[], String) line: 410
> RemoteTestRunner.run() line: 294
> RemoteTestRunner.main(String[]) line: 182
> 
> I understand that the presence of SocketComm indicates that I 
> am running in 
> 100% Java mode, no specific native methods (I don't set 
> com.sap.dbtech.jdbc.loadbin = no, but neither do I have the 
> DLL).  Note, 
> some other record deletions in the unit tests do the same 
> thing (freeze), 
> whilst others work - the failure pattern is not obvious to me.
> 
> I notice that in the call to socketread0, timeout==0, I 
> assume that this 
> means if there is no End Of Stream detected, socketread0 will 
> block forever.
> 
> Thanks for any suggestions,
> 
> Brett Randall
> 
> _________________________________________________________________
> Personalise your phone with chart ringtones and polyphonics. Go to  
> http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp
> 
> 
> -- 
> MaxDB Discussion Mailing List
> For list archives: http://lists.mysql.com/maxdb
> To unsubscribe:    
http://lists.mysql.com/[EMAIL PROTECTED]

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to