It's very high performance but I have asking about the software architectural design decisions that led to the change being made.
On Wed, Jul 6, 2016 at 7:03 PM, Paul Mandeltort <p...@marcospec.com> wrote: > This a really high performance app? Without knowing anything about the app > that sounds like that stuff should be stored in the entity engine. That's > pretty much what it does, store values across multiple requests in a multi > user environment. :) > > --P > > > On Jul 6, 2016, at 12:53 AM, Justin Robinson < > ofbiz-10.04-downst...@fluidnotions.com> wrote: > > > > So I followed the advice of Paul and Nicolas in a previous thread, and > > started refactoring the framework of this code base build around ofbiz > 10.04 > > > > I merged and ported mainly the code that removes static sychronized > blocks > > and updated the libraries accordingly. > > > > One major issue I now have is the immutable nature of DispatchContext, > this > > makes it thread safe as explained in the code comments. > > > > There are lots of serves that use the attributes map in DispatchContext > to > > store values across requests. > > > > Does anyone have an ideas on how I should fix this. I can do large scale > > automated refactorings using spoon, but I could use some advice from an > > implementation design perspective. > > > > I'm trying to figure out a thread safe way hold these attributes with > would > > be available in the same method context that DispatchContext is > available. > > But since the nature of these attributes is that they remain constant > > across many requests so they even need to be threadsafe? >
