AW: Java program interferring with Tomcat
Sounds like a deadlock on the database. To verify that have a look at the server manager to see if there are locks. Which SQL Server Version do you use? Which transaction level do you use? (java.sql.Connection.getTransactionIsolation()) -Ursprüngliche Nachricht- Von: David Frankson [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 19. November 2001 18:17 An: tomcat-user Betreff: Java program interferring with Tomcat I have a server running Tomcat 4.0 on Win2k with the Sun VM JRE 1.3.1. At 11am each day I have a commandline Java program scheduled to run using Window's scheduler. When this program runs, Tomcat becomes unresponsive. The process appears to still be running, but I need to restart it to get it to continue serving pages. There are no errors in any logs. The only shared resource between the two programs is SQL Server. There are two processes running, so both programs should be in seperate VMs. Any ideas? Dave -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: Java program interferring with Tomcat
Ralph Einfeldt wrote: Sounds like a deadlock on the database. To verify that have a look at the server manager to see if there are locks. I agree with Ralph, that the problem is probably in your SQL access. Do *both* processes hang (e.g. Tomcat the scheduled job) or only Tomcat? I would also look at a thread dump to see what thread is locked where. Go to the window in which Tomcat is running and do a Control-Break. This is usually easier if you've started Tomcat with run, not start. dwh -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: Java program interferring with Tomcat
Only Tomcat hangs, the other program continues on. I thought a database deadlock only happens when both threads are trying to write and holding a lock on each other's data? The external java process is read-only. How do you do a thread-dump on when you are running Tomcat as a service on Win2k? Dave - Original Message - From: Denis Haskin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 19, 2001 12:09 PM Subject: Re: AW: Java program interferring with Tomcat Ralph Einfeldt wrote: Sounds like a deadlock on the database. To verify that have a look at the server manager to see if there are locks. I agree with Ralph, that the problem is probably in your SQL access. Do *both* processes hang (e.g. Tomcat the scheduled job) or only Tomcat? I would also look at a thread dump to see what thread is locked where. Go to the window in which Tomcat is running and do a Control-Break. This is usually easier if you've started Tomcat with run, not start. dwh -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: Java program interferring with Tomcat
David Frankson wrote: Only Tomcat hangs, the other program continues on. I thought a database deadlock only happens when both threads are trying to write and holding a lock on each other's data? The external java process is read-only. Hmm. That's why I asked. Sounds like maybe the db deadlock idea is not the right track. How do you do a thread-dump on when you are running Tomcat as a service on Win2k? Yikes! Good question. For testing, would it be difficult to run your Tomcat from a command prompt instead? On Unix you get the thread dump by sending a signal to the JVM, which would be nice in this case... hmm... dwh -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: AW: Java program interferring with Tomcat
-Original Message- From: David Frankson [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 1:42 PM To: Tomcat Users List Subject: Re: AW: Java program interferring with Tomcat Only Tomcat hangs, the other program continues on. I thought a database deadlock only happens when both threads are trying to write and holding a lock on each other's data? The external java process is read-only. Not with SQL Server. If thread A has a write lock on a table, thread b will wait until the write is completed before reading. If thread A is in a transaction that is long running then a perfectly funcitoning application can seem to hang. Its also possible that some form of infinite loop or deadlock in thread A could cause it to never release the transaction, making you either kill the application or use Enterprise Manager to kill the lock. How do you do a thread-dump on when you are running Tomcat as a service on Win2k? Dave - Original Message - From: Denis Haskin [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, November 19, 2001 12:09 PM Subject: Re: AW: Java program interferring with Tomcat Ralph Einfeldt wrote: Sounds like a deadlock on the database. To verify that have a look at the server manager to see if there are locks. I agree with Ralph, that the problem is probably in your SQL access. Do *both* processes hang (e.g. Tomcat the scheduled job) or only Tomcat? I would also look at a thread dump to see what thread is locked where. Go to the window in which Tomcat is running and do a Control-Break. This is usually easier if you've started Tomcat with run, not start. dwh -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: Java program interferring with Tomcat
Not with SQL Server. If thread A has a write lock on a table, thread b will wait until the write is completed before reading. If thread A is in a transaction that is long running then a perfectly funcitoning application can seem to hang. Its also possible that some form of infinite loop or deadlock in thread A could cause it to never release the transaction, making you either kill the application or use Enterprise Manager to kill the lock. Does changing the transaction isolation level affect things? The tomcat application is a high traffic transactional system, and the commandline app is a read-only data export tool that fires off twice a day. Both are set to TRANSACTION_READ_COMMITTED. Dave -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: AW: Java program interferring with Tomcat
I've never tried to do this because I never wanted dirty data (i.e. part of what someone else wrote, possibly including data to be rolled back, etc). Randy -Original Message- From: David Frankson [mailto:[EMAIL PROTECTED]] Sent: Monday, November 19, 2001 2:42 PM To: Tomcat Users List Subject: Re: AW: Java program interferring with Tomcat Not with SQL Server. If thread A has a write lock on a table, thread b will wait until the write is completed before reading. If thread A is in a transaction that is long running then a perfectly funcitoning application can seem to hang. Its also possible that some form of infinite loop or deadlock in thread A could cause it to never release the transaction, making you either kill the application or use Enterprise Manager to kill the lock. Does changing the transaction isolation level affect things? The tomcat application is a high traffic transactional system, and the commandline app is a read-only data export tool that fires off twice a day. Both are set to TRANSACTION_READ_COMMITTED. Dave -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: AW: Java program interferring with Tomcat
Sure it does. Changing the transaction isolation level affects how data is read from the database. TRANSACTION_READ_COMMITTED waits for a read lock before reading data and ensures that the data being read is in a consistent state. Lower isolation levels may allow data to be read that's inconsistent -- data from a transaction that hasn't been committed, yet, and therefore may be rolled back. However, that doesn't mean lower isolation levels are bad. They can relieve a lot of locking contention on the database when used with queries that don't need perfectly consistent data. It just depends on how critical the info you're pulling with this particular query is. For example: are you tallying the number of visitors to your website or are you doing financial transactions? With the former, reading dirty data may not matter that much. With the latter, it may be critical that you have consistent data. If your data's not that critical, you may get a lot of benefit from lowering your transaction isolation level. Thanks, --jeff - Original Message - From: David Frankson [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Monday, November 19, 2001 11:42 AM Subject: Re: AW: Java program interferring with Tomcat Not with SQL Server. If thread A has a write lock on a table, thread b will wait until the write is completed before reading. If thread A is in a transaction that is long running then a perfectly funcitoning application can seem to hang. Its also possible that some form of infinite loop or deadlock in thread A could cause it to never release the transaction, making you either kill the application or use Enterprise Manager to kill the lock. Does changing the transaction isolation level affect things? The tomcat application is a high traffic transactional system, and the commandline app is a read-only data export tool that fires off twice a day. Both are set to TRANSACTION_READ_COMMITTED. Dave -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
