Hi David, yes, the thread-local vars are thread safe. However in order to assign them a synchronized block or method is needed. There is no way to avoid synchronized block if we want to create a transaction using a static method without any arguments or without making the caller to keep a return value in a local variable ( public void TransactionUtil.begin() ). The begin() method needs to create a thread-local var and associate it with the currently running thread.
A workaround could be to use something like : UserTransaction transaction = TransactionUtil.createNewTransaction(); //... execute code TransactionUtil.commit( transaction ); this way we don't need any thread-local vars. However this approach would require to make lots of fixes in the existing code and this can not happen quickly. We've got to think of something else. -- Deyan On Tue, 2010-06-01 at 03:16 -0600, David E Jones wrote: > To be clear, I wasn't recommending that we remove synchronized from the begin > method in OFBiz, just that they remove it temporarily and then redo their > performance tests to see if that really is the problem. > > You're absolutely right that more work will be necessary to localize the > synchronization to avoid bottlenecks on a larger block of code. > > BTW, the three sub-method calls you mentioned should all only deal with > thread-local variables... aren't those thread-safe to use? > > -David > > > On Jun 1, 2010, at 12:42 AM, Deyan Tsvetanov wrote: > > > I take my words back about the workaround. > > It's much more complicated. > > > > On Tue, 2010-06-01 at 09:23 +0300, Deyan Tsvetanov wrote: > >> Hi guys, > >> > >> removing synchronized from begin( int timeout) will cause issues. > >> The problematic code is the following: > >> (starting from line 180 in TransactionUtil.java - trunk ) > >> > >> // reset the transaction stamps, just in case... > >> > >> clearTransactionStamps(); > >> // initialize the start stamp > >> getTransactionStartStamp(); > >> // set the tx begin stack placeholder > >> setTransactionBeginStack(); > >> > >> So the synchronized begin() is a huge bottleneck and imho it can't be > >> solved without coding. Caching is not a solution. > >> I think the transaction timestamps and the transaction begin stack have > >> to be moved to the UserTransaction so they are not static anymore. > >> In general TransactionUtil needs some rework. > >> > >> Cheers, > >> Deyan > >> > >> On Mon, 2010-05-31 at 14:34 -0600, David E Jones wrote: > >>> The theory that Martin mentioned is interesting, and quite possible. Have > >>> you tried removing the synchronized keyword from the begin method to see > >>> if it helps? > >>> > >>> That would just be to test the theory, and if that does turn out to be > >>> the bottleneck then the sensitive parts of the method should be > >>> synchronized (or put into separate synchronized methods) instead of > >>> snycing the whole method. > >>> > >>> -David > >>> > >>> > >>> On May 31, 2010, at 2:24 PM, Karl Pitrich wrote: > >>> > >>>> Hi, > >>>> > >>>> I'm working with Martin on this project. > >>>> > >>>> We have commented the various cache options as described in the Wiki > >>>> (and mailing list), > >>>> EXPIRE TIME is 0 in all except for product.* when viewing > >>>> /webtools/control/FindUtilCache > >>>> > >>>> Logging is disabled, as are several components. > >>>> Also, we have disabled several content elements from the template, such > >>>> as recommendations or polls, etc. > >>>> > >>>> > >>>> Any help is appreciated, > >>>> Greetings, > >>>> > >>>> - Karl > >>>> > >>>> On 31.05.2010, at 22:07, Jacques Le Roux wrote: > >>>> > >>>>> 1st level of answer, did you set caches? > >>>>> https://cwiki.apache.org/confluence/display/OFBTECH/Apache+OFBiz+Technical+Production+Setup+Guide#ApacheOFBizTechnicalProductionSetupGuide-CacheSettings > >>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Scaling+and+Performance+Plan > >>>>> > >>>>> Jacques > >>>>> > >>>>> From: "Martin Kreidenweis" <martin.kreidenw...@tngtech.com> > >>>>>> Hi, > >>>>>> > >>>>>> we are currently evaluating Apache OFBiz for use in one of our > >>>>>> projects. > >>>>>> > >>>>>> We expect a high load on our application. So we did a test with jMeter > >>>>>> on the sample ecommerce application with 100 parallel sessions and in > >>>>>> average 400 msec (randomized) wait time between requests. > >>>>>> > >>>>>> During profiling we experienced that > >>>>>> org.ofbiz.entity.transaction.TransactionUtil.begin() is by far the > >>>>>> dominating method invoked and the application spends about 75% of total > >>>>>> time in this method. > >>>>>> This results in page load times over 10 seconds and growing. > >>>>>> > >>>>>> Many threads are blocked because the method is defined as static and > >>>>>> synchronized. > >>>>>> > >>>>>> We are using MySQL as a database backend in our test setup and > >>>>>> deactivated all informational logging (even server hit statistics), and > >>>>>> most of the sidebar widgets. > >>>>>> > >>>>>> Any suggestions/ideas are highly appreciated. > >>>>>> Thanks. > >>>>>> > >>>>>> Best regards, > >>>>>> Martin > >>> > >> > >> > > > > >
