We upgraded from Servoy 3.1 to 6.1, and now get Deadlock errors in the Server Log
using Sybase 10.0.1
it’s a simple Form with a Tab Panel. A Global Method Finds the records in each Tab Panel form
The server log shows what looks like two Load Found Set queries: e.g. “Select serial_numbers from Table …” and "Select columns From Table where serial_number IN … "
it is our main page, so it happens often, with about 9 users
any way to debug this ?
greg
Greg,
Do you use long-running transactions?
Can you show the error from the log file?
Rob
We have no real “transactions”, but do run some report queries that might take up to a minute to complete
This is the error:
com.sybase.jdbc3.jdbc.SybSQLException: SQL Anywhere Error -306: Deadlock detected
at com.sybase.jdbc3.tds.Tds.a(Unknown Source)
at com.sybase.jdbc3.tds.Tds.nextResult(Unknown Source)
at com.sybase.jdbc3.tds.TdsResultSet.nextResult(Unknown Source)
at com.sybase.jdbc3.tds.TdsResultSet.next(Unknown Source)
at com.sybase.jdbc3.jdbc.SybCursorResultSet.next(Unknown Source)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:207)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:207)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:207)
at org.apache.commons.dbcp.DelegatingResultSet.next(DelegatingResultSet.java:207)
at com.servoy.j2db.dataprocessing.Zv.createBufferedDataSet(Zv.java:671)
at com.servoy.j2db.dataprocessing.Zv.Za(Zv.java:989)
at com.servoy.j2db.dataprocessing.Zv.Za(Zv.java:1001)
at com.servoy.j2db.dataprocessing.Zv.Za(Zv.java:57)
at com.servoy.j2db.dataprocessing.Zv.performQuery(Zv.java:1250)
at sun.reflect.GeneratedMethodAccessor116.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
at sun.rmi.transport.Transport$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Greg,
Sounds to me that a foundset query (which is always pk-based) should not take a minute.
I guess the client query is blocked and selected as deadlock victim after some time.
Check what else is running when 1 client is blocked.
The admin page in 6.1 also shows running queries.
Rob
Using Application Profiling in Sybase Central, it appears that the server requests are fighting for the same connection
It seems the Sybase locking scheme by default is “allpages”. Perhaps I could make this “datapages”
The database has the default 10 Active and 5 Idle connections. Doubling this makes no difference
idle timeout is -1
We usually have 8 or 9 concurrent users
greg
( cont’d )
From the Server Log, I see e.g. 14 deadlock errors in one minute, from 7 of the 9 clients
They are ALL trying to Load Foundset, from the same Table
Perhaps a record was edited, and the change is being broadcast ?
Since the Performance Log does not give Date and Time, it is hard to tell which query starts it
greg
I found a post from Johan C, saying you should never just “ShowForm”. That it must have a Found Set
Is this still true ? Perhaps this is my problem …
In my “opener” method, I do start with a Found Set in all Tables
greg
I see now that this is a data broadcast problem, and have posted it here instead:
greg