OK - I did some more testing this afternoon. (reading some SQL Server/
Driver manuals etc).
I have switched to the latest MSFT driver, and I still see a sporadic
hang. However, I have also reduced the lock timeout from Indefinitely
(default value apparently) to 20 seconds. The app no longer hangs,
and rolls back just fine.
However, my big question now is this: Is it correct to assume that a
DB will reach deadlock at some point?
Maybe I was spoiled with MySQL - but we never had deadlock there, and
still don't even in all our production deployments. Any insight from
this group?
Thanks,
George-
On Oct 30, 2006, at 4:00 PM, Ralf Joachim wrote:
George,
take a look at http://castor.codehaus.org/how-to-connection-
proxies.html on how to enable logging of SQL statements. Especially
take a look at locking as Werner suggested.
Regards
Ralf
George Rebens schrieb:
Ralf,
I am using just a simple driver at this point.
In regards to logging, hey why not, I will try anything at this
point;) Let me know how to turn it on, and also what you suggest
that I look for.
Thanks,
George-
On Oct 30, 2006, at 4:00 AM, Ralf Joachim wrote:
Hi George,
are you using simple driver or datasource driver with connection
pooling? May the number of max. concurrent connections be
exceeded or
are your connections timed out according to some settings on
driver or
database engine.
Having said that I have no experience with SQL server, but I
such things
do not happen to me at oracle. Internally castor handles all
database
engines quite similar except that the SQL statements executed vary a
bit. If you think, logging of SQL statements may help you, I could
instruct you how to enable this in castor.
Regards
Ralf
George Rebens schrieb:
I have a highly threaded application - each thread does several
read/
writes within their lifetime. The application works fine with MySQL
(InnoDb tables), but when we ported the schema to SQL Server we
have
been running into sporadic problems.
It seems like SQLServer is not honoring the transactions
properly, as
when i change my MySQL tables to ISAM , I get nearly the same
behavior
from MySQL.
A bit further of investigation in my app, and it seems that my
attempts
to load object A in one thread (for writing). Thread 2 does a
query to
load (read only) and the two seem to lock. In the SQL Server
enterprise
manager I can see the lock hanging there.
This does not happen all the time, and is rather sporadic. Since I
don't have these issues at ALL in MySQL, am I wrong to believe
that SQL
Server should do the same?
Is there a better driver choice, or do i need to somehow enable
transactions in SQL Server?
Any help is appreciated.
-- JTDS driver, SQL Server 2000.
Example Trace below:
ERROR 2006-10-19 17:17:26.593 .LocalDatabaseImpl } }
[Thread-574] This transaction has been aborted and rolled
back: Nested
error: org.exolab.castor.jdo.TransactionAbortedException: Nested
error: java.sql.SQLException: Invalid state, the Connection
object is
closed.: Invalid state, the Connection object is closed.:
Nested error:
java.sql.SQLException: Invalid state, the Connection object is
closed.:
Invalid state, the Connection object is closed.
org.exolab.castor.jdo.TransactionAbortedException: Nested error:
org.exolab.castor.jdo.TransactionAbortedException: Nested error:
java.sql.SQLException: Invalid state, the Connection object is
closed.:
Invalid state, the Connection object is closed.: Nested error:
java.sql.SQLException: Invalid state, the Connection object is
closed.:
Invalid state, the Connection object is closed. at
org.castor.persist.AbstractTransactionContext.commit
(AbstractTransactionContext.java:1322) at
org.exolab.castor.jdo.engine.LocalDatabaseImpl.commit
(LocalDatabaseImpl.java:170)
Thanks,
George-
-------------------------------------------------------------------
--
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--------------------------------------------------------------------
-
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
