RE: [JBoss-dev] [ jboss-Feature Requests-430946 ] Reporting transaction failures
please stop sending this crap -Original Message- From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]] Sent: Thursday, June 07, 2001 6:25 AM To: [EMAIL PROTECTED] Subject: [JBoss-dev] [ jboss-Feature Requests-430946 ] Reporting transaction failures Feature Requests item #430946, was updated on 2001-06-06 22:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=430946group_i d=22866 Category: None Group: None Status: Open Priority: 5 Submitted By: Marco Hunsicker (marcohu) Assigned to: Nobody/Anonymous (nobody) Summary: Reporting transaction failures Initial Comment: I have a 'feature request' regarding the transaction implementation of the beloved JBoss. I'm currently testing an EJB entity bean and detected the following issue: In the case where a user tries setting invalid data and this data is about to be synchronized with the database, my bean throws a java.lang.IllegalArgumentException with a detailed (and useful!) exception message. This exception is caught in ejbStore(), encapsulated with an EJB Exception and rethrown as to explain my implementation of the bean. The JBoss log file exposes this behaviour as the EJBException shows up there. I expected the pending transaction to be rolled back and my thrown EJBException travelling through the proxy to the client to indicate the error. Indeed, the transaction is unable to commit, but instead of the root cause, the client gets an javax.transaction.RolledbackException with no explanation of the error. Hm, the RollbackException makes sense to me, as the database rejected the change. But it would be much better if the exception could be holding information about the reason why the transaction failed. The JDK javadocs states that javax.transaction.RollbackExcetion is a 'local' exception. So if we want to pass a transaction exception back to the client it maybe would be better to throw a javax.transaction.TransactionRolledbackExeption instead (having the 'detail' field to store the cause). Clients would then be able to resolve the root cause. Skimming through TxCapsule.java (where the RollbackException originates, I'm refering the JBoss 2.2.2 release source), I've learned that every transaction has its own context. Therefore, what about adding a member field for the exception causing a status change? Then we would be able to throw a javax.transaction.TranscationRolledbackException which holds the root cause in its 'detail' field. This of course, would mean changes to all the dependend classes as well. Maybe these will be possible in an upcoming release... Cheers, M.H. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376688aid=430946group_i d=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fast Updates Based on Row ID
Will put in checks for null rowids. Need to figure out a way of changing the inserts as well. Will probably be only tomorrow though. Vinay - Original Message - From: danch [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 07, 2001 6:32 AM Subject: Re: [JBoss-dev] Fast Updates Based on Row ID K.V. Vinay Menon wrote: Dan Ch, Well as you might have noticed the code will work as usual if the rowid-column field is not specified in jaws.xml. If it is specified, it will then be used instead of the primary key. I am not sure of how other databases work with rowids which is why jaws will still default to normal behaviour. I think i'd rather have a flag on the JAWS entity to turn on 'oracle-tuned-updates' than just indicating the name of the rowid column. That way people will be less likely to turn it on for other databases. Do you think we are in a position to submit the source? I'd have rather sent the modified source files for peer review in case I have goofed up! And *then* committed changes. Do you have the time to spare? I think we've gotten a pretty good peer review already. However, with the insert issue and the change Georg points out later (detect empty rowIDValue and fall back on primary key) I think you should probably work those ideas into the code and post again. Are you on the JBossCMP mailing list? Perhaps we should move this discussion there. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Another possible bug related to this same problem. [please read below]. EntityInstanceInterceptor gets the mutex of the Entity's key before going into the do..while loop. If a different thread/transaction rollsback, the mutex gets detached from the EntityEnterpriseContext and the thread in the do..while loop is acquiring a lock on a context that is not attached. Am I missing something here? I'd really like to go in and fix this problem, but I really need another set of eyeballs to make sure I'm doing things right. Danch, can you volunteer to help? Also, while I'm in this code, maybe I should consider adding the Missing wait/notify and remove that buggy do..while loop as well. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Wednesday, June 06, 2001 9:39 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization? All, I'm wondering if I've found a race condition bewteen EntityInstanceInterceptor and EntitySynchronizationInterceptor.InstanceSynchronization. Scenario: Transaction A Transaction B Grab and lock Entity 123 Wait for Entity 123 to get release from Trans A in EntityInstanceInterceptor Rollback in InstanceSynchronization.afterCompletion() if (status == Status.STATUS_ROLLEDBACK ... call ctx.setTransaction(null); in EntityInstanceInterceptor: // Next code returns null Transaction tx = ctx.getTransaction(); // remove from the cache container.getInstanceCache().remove(ctx.getCacheKey()); // return to pool container.getInstancePool().free(ctx); Thread continues with a freed Context == Am I missing something here? How to fix if I'm not? The reason I've been looking into this is because I'm seeing some very weird behaviour where an EntityBean is totally out of whack with what is really within the database. The EntityBean actually has the data of a different EntityBean. When I stop accessing this EntityBean after many different calls within succession and within different transactions the problem disappears after awhile and the EntityBean seems to revert to what is stored within the database. My guess is that the Bean gets dump from the InstanceCache. Regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Bill Burke wrote: Another possible bug related to this same problem. [please read below]. EntityInstanceInterceptor gets the mutex of the Entity's key before going into the do..while loop. If a different thread/transaction rollsback, the mutex gets detached from the EntityEnterpriseContext and the thread in the do..while loop is acquiring a lock on a context that is not attached. Am I missing something here? I don't think so. Do we need to mark the mutex as invalid? When we add teh wait/notify, invalidation should also notify. I'd really like to go in and fix this problem, but I really need another set of eyeballs to make sure I'm doing things right. Danch, can you volunteer to help? Also, while I'm in this code, maybe I should consider adding the Missing wait/notify and remove that buggy do..while loop as well. I can certainly review. I won't have much time for investigation until this evening, and then my wife may have other plans for my time. -danch Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
[JBoss-dev] Verifier Patch
Juha, For the verifier fix what on earth is the spec id .. 9..2.x.x? Any pointers would be much appreciated. Can check in the source once I get the correct value! Vinay
[JBoss-dev] CVS update: manual/src/docs/images netbeans-debug.png netbeans-project.png
User: jwalters Date: 01/06/07 09:10:06 Modified:src/docs/images netbeans-debug.png netbeans-project.png Log: Need to re-checkin as they weren't originally added as binary files - Thanks to Tobias Revision ChangesPath 1.2 +1 -1 manual/src/docs/images/netbeans-debug.png Binary file 1.2 +1 -1 manual/src/docs/images/netbeans-project.png Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
Hi, We've noticed the enormous traffic between client and server. Investigation showed that the problem is in MarshalledObject: ...classes are annotated with a codebase URL from where the class can be loaded (if available), which means that when the enclosed object was loaded via URLClassLoader, then the list of all URLs of the classloader is enclosed in the MarshalledObject instance. This list includes full names of all jar-files residing in the local filesystem, in any case they can't be used on the remote computer. In our project we use URLClassLoader in the client application, JBoss and underlying JMX library use it as well, the result is awful. My proposition to JBoss developers: to introduce own class which would do the same things as the standard MarshalledObject class, but will not enclose the URLs list, or will contain only non-file: URLs (http:, ftp:), which can be used on the remote machine, at least theoretically. I will implement this idea when/if it meets with approval. Comments are appreciated. Oleg ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
This really should be fixed by having a new URLClassLoader subclass that returns the java.rmi.server.codebase so that code can be properly downloaded to the clients while still loading classes from the local urls. This fixes the current dynamic class loading problem. I have a solution based on what Vlad and Sacha had mentioned in their investigation of the problem that I'm going to commit next week. - Original Message - From: Oleg Nitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 07, 2001 9:27 AM Subject: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic Hi, We've noticed the enormous traffic between client and server. Investigation showed that the problem is in MarshalledObject: ...classes are annotated with a codebase URL from where the class can be loaded (if available), which means that when the enclosed object was loaded via URLClassLoader, then the list of all URLs of the classloader is enclosed in the MarshalledObject instance. This list includes full names of all jar-files residing in the local filesystem, in any case they can't be used on the remote computer. In our project we use URLClassLoader in the client application, JBoss and underlying JMX library use it as well, the result is awful. My proposition to JBoss developers: to introduce own class which would do the same things as the standard MarshalledObject class, but will not enclose the URLs list, or will contain only non-file: URLs (http:, ftp:), which can be used on the remote machine, at least theoretically. I will implement this idea when/if it meets with approval. Comments are appreciated. Oleg ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
Hi Scott, Thanks for your answer. I am afraid you speak about another problem. At least I don't believe that the problem that I'm speaking about can be solved in a subclass of URLClassLoader. If MarshalledObject gets an object in the constructor, which is loaded by any subclass of URLClassLoader, MarshalledObject calls getURLs() on it and stores the result inside itself, so that the array of all URLs from client's classpath is sent to the server together with each minor parameter, and all URLs from the server's classpath are sent to client together with each return value (if its class is not in the system classpath). Just to make it clear: currently we are not going to use dynamic class loading at all, we have all needed classes on the client, we are anxious about the unnecessary network traffic. And this traffic is absolutely stupid, to be honest :-) Oleg Scott M Stark wrote: This really should be fixed by having a new URLClassLoader subclass that returns the java.rmi.server.codebase so that code can be properly downloaded to the clients while still loading classes from the local urls. This fixes the current dynamic class loading problem. I have a solution based on what Vlad and Sacha had mentioned in their investigation of the problem that I'm going to commit next week. - Original Message - From: Oleg Nitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 07, 2001 9:27 AM Subject: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic Hi, We've noticed the enormous traffic between client and server. Investigation showed that the problem is in MarshalledObject: ...classes are annotated with a codebase URL from where the class can be loaded (if available), which means that when the enclosed object was loaded via URLClassLoader, then the list of all URLs of the classloader is enclosed in the MarshalledObject instance. This list includes full names of all jar-files residing in the local filesystem, in any case they can't be used on the remote computer. In our project we use URLClassLoader in the client application, JBoss and underlying JMX library use it as well, the result is awful. My proposition to JBoss developers: to introduce own class which would do the same things as the standard MarshalledObject class, but will not enclose the URLs list, or will contain only non-file: URLs (http:, ftp:), which can be used on the remote machine, at least theoretically. I will implement this idea when/if it meets with approval. Comments are appreciated. Oleg ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic
Hello Oleg, But I think that the getURLs() method of the new class (that will subclass URLClassLoader), will only return the http://... URL from where code can be downloaded. The method will not prompt every classloader in the chain for their URLs. The goal of this new class is (almost) only to override the behaviour of the getURLs method to return only a single URL. HTH. Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de Oleg Nitz Envoye : jeudi, 7 juin 2001 19:32 A : Scott M Stark Objet : Re: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic Hi Scott, Thanks for your answer. I am afraid you speak about another problem. At least I don't believe that the problem that I'm speaking about can be solved in a subclass of URLClassLoader. If MarshalledObject gets an object in the constructor, which is loaded by any subclass of URLClassLoader, MarshalledObject calls getURLs() on it and stores the result inside itself, so that the array of all URLs from client's classpath is sent to the server together with each minor parameter, and all URLs from the server's classpath are sent to client together with each return value (if its class is not in the system classpath). Just to make it clear: currently we are not going to use dynamic class loading at all, we have all needed classes on the client, we are anxious about the unnecessary network traffic. And this traffic is absolutely stupid, to be honest :-) Oleg Scott M Stark wrote: This really should be fixed by having a new URLClassLoader subclass that returns the java.rmi.server.codebase so that code can be properly downloaded to the clients while still loading classes from the local urls. This fixes the current dynamic class loading problem. I have a solution based on what Vlad and Sacha had mentioned in their investigation of the problem that I'm going to commit next week. - Original Message - From: Oleg Nitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 07, 2001 9:27 AM Subject: [JBoss-dev] MarshalledObject + URLClassLoader = huge network traffic Hi, We've noticed the enormous traffic between client and server. Investigation showed that the problem is in MarshalledObject: ...classes are annotated with a codebase URL from where the class can be loaded (if available), which means that when the enclosed object was loaded via URLClassLoader, then the list of all URLs of the classloader is enclosed in the MarshalledObject instance. This list includes full names of all jar-files residing in the local filesystem, in any case they can't be used on the remote computer. In our project we use URLClassLoader in the client application, JBoss and underlying JMX library use it as well, the result is awful. My proposition to JBoss developers: to introduce own class which would do the same things as the standard MarshalledObject class, but will not enclose the URLs list, or will contain only non-file: URLs (http:, ftp:), which can be used on the remote machine, at least theoretically. I will implement this idea when/if it meets with approval. Comments are appreciated. Oleg ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
FYI, There definately is a race condition. I modified InstanceSynchronization and put a sleep after ctx.setTransction(null) and had 2 threads accessing the same bean. When thread 1 rolled back and slept after the setTransaction(null), thread 2 wokeup. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Thursday, June 07, 2001 11:42 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of danch (Dan Christopherson) Sent: Thursday, June 07, 2001 11:00 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization? Bill Burke wrote: Another possible bug related to this same problem. [please read below]. EntityInstanceInterceptor gets the mutex of the Entity's key before going into the do..while loop. If a different thread/transaction rollsback, the mutex gets detached from the EntityEnterpriseContext and the thread in the do..while loop is acquiring a lock on a context that is not attached. Am I missing something here? I don't think so. Do we need to mark the mutex as invalid? When we add teh wait/notify, invalidation should also notify. I'd really like to go in and fix this problem, but I really need another set of eyeballs to make sure I'm doing things right. Danch, can you volunteer to help? Also, while I'm in this code, maybe I should consider adding the Missing wait/notify and remove that buggy do..while loop as well. I can certainly review. I won't have much time for investigation until this evening, and then my wife may have other plans for my time. Thanks. My wife has veto power as well :-) It may take me awhile to come up with a solution anyways. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/resources/org/jboss/verifier DefaultMessages.properties
User: kvvinaymenon Date: 01/06/07 14:23:31 Modified:src/resources/org/jboss/verifier DefaultMessages.properties Log: Added message 9.2.7.h for validating the Remote Interface as throwing valid RMI/IIOP types. Revision ChangesPath 1.10 +1 -0 jboss/src/resources/org/jboss/verifier/DefaultMessages.properties Index: DefaultMessages.properties === RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/verifier/DefaultMessages.properties,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- DefaultMessages.properties2000/11/14 19:54:32 1.9 +++ DefaultMessages.properties2001/06/07 21:23:31 1.10 @@ -74,6 +74,7 @@ 9.2.7.e = For each method defined in the remote interface, there must be a matching method in the entity bean's class that has the same name and argument types. 9.2.7.f = For each method defined in the remote interface, there must be a matching method in the entity bean's class that has the same return type. 9.2.7.g = All the exceptions defined in the throws clause of a matching method in the entity bean's class must be defined in the throws clause of the method of the remote interface. +9.2.7.h = The exceptions thrown by methods in the remote interface must be valid types for RMI/IIOP 9.2.8.a = Entity bean's home interface must extend the javax.ejb.EJBHome interface. 9.2.8.b = The method arguments in the home interface must be of valid types for RMI/IIOP. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
JBoss daily test results SUMMARY Number of tests run: 68 Successful tests: 57 Errors:1 Failures: 10 [time of test: 8 June 2001 2:47] See http://lubega.com for full details DETAILS OF ERRORS Suite: org.jboss.test.cts.test.AllJUnitTests Test:testRemoveSessionObject Type:failure Exception: junit.framework.AssertionFailedError Message: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) Stack Trace: junit.framework.AssertionFailedError: [EJB 1.1, p42, section 5.3.2] Expected 'RemoveException' when remove-ing a session object, detail:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory); nested exception is: java.rmi.NoSuchObjectException: Could not activate; nested exception is: java.io.FileNotFoundException: [EMAIL PROTECTED] (No such file or directory) at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testRemoveSessionObject(StatefulSessionTest.java:188) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testProbeBeanContext Type:failure Exception: junit.framework.AssertionFailedError Message: Caught an unknown exception in testProbeBeanContex Stack Trace: junit.framework.AssertionFailedError: Caught an unknown exception in testProbeBeanContex at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.StatefulSessionTest.testProbeBeanContext(StatefulSessionTest.java:467) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.cts.test.AllJUnitTests Test:testEjbRemove Type:failure Exception: junit.framework.AssertionFailedError Message: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. Stack Trace: junit.framework.AssertionFailedError: Got Exception: expecting NoSuchObjectExceptionjava.rmi.ServerException: RemoteException occurred in server thread; nested exception is: javax.transaction.TransactionRolledbackException: Instance 007 not found in database.; nested exception is: javax.ejb.NoSuchEntityException: Instance 007 not found in database. at junit.framework.Assert.fail(Assert.java:143) at org.jboss.test.cts.test.BmpTest.testEjbRemove(BmpTest.java:224) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155)
Re: [JBoss-dev] race condition between EntityInstanceInterceptor and InstanceSynchronization?
Dear Bill and Dan, I'd really like to go in and fix this problem, but I really need another set of eyeballs to make sure I'm doing things right. Danch, can you volunteer to help? Also, while I'm in this code, maybe I should consider adding the Missing wait/notify and remove that buggy do..while loop as well. I can certainly review. I won't have much time for investigation until this evening, and then my wife may have other plans for my time. I would be really happy, if you both could manage to correct the wait/notify issue while on that code and fixing the race condition. Besides, I just answered a message, where someone seemed to have a deadlock, that remained unresolved, though server log messages told, that the transactions timed out (3 TX reported). The guy had to restart JBoss, the log was filled up with LOCKING-WAITING (TX). best regards Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 PS: I don't think, I can really help, but I'll follow this thread maybe at least I can document something. ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
