Refactoring downstream customization to ofbiz 13 dealing with immutable DispatchContext breaking changes

[Justin Robinson-2]

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?

[marcopaul]

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 <[hidden email]> 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?

[Justin Robinson-2]

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 <[hidden email]> 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 <
> [hidden email]> 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?
>