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
