I think what Adrian means to say is that if you use the higher level tools in OFBiz such as the simple-methods instead of writing code in Java you're not as likely to run into concurrency issues.
More generally, OFBiz consists of a fairly large body of code and is created by a large number of contributors. For the most part code in the OFBiz Framework is widely used and pretty well tested, and when there are concurrency problems they generally get fixed (that's no guarantee, just a general trend). In addition to the possibility of concurrency problems in framework code, there is also a possibility of concurrency problems in business logic, especially business logic written in Java. Most business logic in OFBiz runs through the Service Engine, which coordinates the calling of stateless services. Even services written in Java as static methods are fine as long as they don't refer to static variables, or as long as they do so in a way that is thread-safe (like objects written to handle concurrency). The idea that all static methods need to be synchronized is totally unfounded. You can do so if you wish, but it will kill performance and most of the time do nothing to help with concurrency issues. In fact, it will cause concurrency problems of all sorts and make your system scale really poorly, to the point of causing frequent errors and failures with timeouts, deadlocks, and so on. You're right about the testing aspect. If you are concerned about concurrency issues, the only thing to do is learn about concurrency in Java, and test specifically for concurrency (The Grinder is a pretty good open source tool kit for doing that, and of course there are many others). Please keep in mind though that your intended use may be very different from the intended uses of other users of OFBiz, so again if there are things you are concerned about with concurrency or anything else, you should test those things. If you want to increase the chances of something working a certain way in the future in OFBiz itself, you should contribute automated test cases to test those things. It's that simple, and there is no substitute. Another benefit of doing that testing is you can try out things like you mentioned, ie making all static methods synchronized, and then see what happens! -David On Sep 3, 2010, at 12:20 PM, Michał Cukierman wrote: > >> You don't need to do that. If >> you stick with the higher level tools you will be more productive and >> have a lot less to worry about. > > Are you sure about that? > Or you just havn't had problems with concurrency issues? > > You can't just use application/framework without knowing whats inside. > For the last year I worked for Aerospace and Defence company, and in > such cases code quality is critical. > > It's just a matter of time/load/data sets sizes, or just a bad luck, > when such a code will be a problem. > > I am not fan of "Luck driven development", so I want to clarify my > concerns in here. But talking like: > "Don't worry, it will work" > Is not a good argument. > > As far as Ofbiz is a small application, it should not be a problem to > fix such issues. just find all static public methods invoked from > multiple threads and make them synchronized. > > > > > > > Dnia 2010-09-03, pią o godzinie 07:16 -0700, Adrian Crum pisze: >> As long as you use the tools OFBiz provides, you do not need to worry >> about concurrency in Java code. OFbiz is a suite of multi-threaded >> applications that serve thousands of simultaneous users. >> >> A common mistake new users make is to go directly to Java code and they >> end up getting mired in details like this. You don't need to do that. If >> you stick with the higher level tools you will be more productive and >> have a lot less to worry about. >> >> -Adrian >> >> On 9/3/2010 6:28 AM, Michał Cukierman wrote: >>> Hi, >>> >>> I am developing custom services and I want to know if invocation of >>> public static methods are handled for example in some introspectors or >>> in FTL controllers. If no - I am gonna to handle it by my own. But in >>> fact I belive I have missed something. >>> >>> So my question is: >>> Is the Ofbiz thread safe? >>> >>> I do not face issues when working on one machine but in the future I >>> excpect more visitors than one. >>> >>> If (If) those methods are not handled in any places, why don't you use >>> synchronized keyword? >>> >>> Regards, >>> Michał Cukierman >>> >>> >>> Dnia 2010-09-03, pią o godzinie 05:55 -0700, Adrian Crum pisze: >>>> What exactly do you need to know? Are you running into any concurrency >>>> issues? >>>> >>>> -Adrian >>>> >>>> --- On Fri, 9/3/10, Michał Cukierman<[email protected]> wrote: >>>> >>>>> From: Michał Cukierman<[email protected]> >>>>> Subject: Re: Ofbiz Concurrency handling >>>>> To: [email protected] >>>>> Date: Friday, September 3, 2010, 12:55 AM >>>>> Can anyone help me with understandin >>>>> Ofbiz concurrency handling? >>>>> Is it thread safe? >>>>> >>>>> Dnia 2010-09-02, czw o godzinie 15:23 +0200, Michał >>>>> Cukierman pisze: >>>>>> Hello, >>>>>> >>>>>> I do ofbiz customization with some code changes. At >>>>> the moment Im >>>>>> extending ecommerce catalog and product structure. >>>>> This action requires >>>>>> additional services to be implemented. >>>>>> >>>>>> So, I am wondering how ofbiz implements concurent >>>>> programing issues. >>>>>> In FTL files in most cases it invokes >>>>>> public, static, NOT synchronized methods. >>>>>> >>>>>> Just an example: >>>>>> http://www.java2s.com/Open-Source/Java-Document/ERP-CRM-Financial/SourceTap-CRM/org/ofbiz/product/category/CategoryWorker.java.htm >>>>>> >>>>>> Are we sure that while invoking: >>>>>> i.e. getRelatedCategories >>>>>> We get our related categories? >>>>>> >>>>>> See: >>>>>> http://tutorials.jenkov.com/java-concurrency/synchronized.html >>>>>> for concurrency basics. >>>>>> >>>>>> Regards, >>>>>> Michał >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >
