Werner - I appreciate the suggestion, and will have a chance to
investigate it this afternoon (CST).
I will advise on progress.
Thanks,
George-
On Oct 30, 2006, at 6:51 AM, Werner Guttmann wrote:
Somehow along these lines, yes. I just had a look at the sources, and
SqlServerQueryExperssion.getStatement() will 'inject'
HOLDLOCK
tokens into the JDBC statement for OQL queries. Not knowing a lot
about
MS SQL server, this could equally cause problems related to what
you are
seeing. It might be worth checking with the manuals that this is what
Castor is meant to be doing wrt SQL server when performing a 'real'
data
base lock.
Just a few cents worth ...
Werner
George Rebens wrote:
Werner,
I checked the locks and - one is the 'select' for the query
thread. The
other is the update from the load thread, as it is about to save the
changes. (at least in the case I just looked at).
Were you suggesting to look at the SQL Manuals in regards to
finding the
correct drivers? I am not sure if I was reading your request
properly.
Thanks,
George-
On Oct 30, 2006, at 4:31 AM, Werner Guttmann wrote:
Another thing that might be useful to check is what the actual LOCK
statement looks like, and check with the SQL Server manuals that
this is
the correct one (i.e. related to version 2000 you seem to be using).
Werner
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
