Thread safety and static properties

[Martin Aspeli]

Hi,

I'm quite interested in Play! as a way to make my Java development
team more productive. I am, however, curious how you deal with thread
safety when request state is stored in static variables. I gather it
relates to the ControllerEnhancer, but I don't really understand how
it works.

I'd be very interested to hear how this pattern works in some more
detail, and perhaps how I could use it in another application.

I'm also curious why you chose this pattern (static variables, thread
local "enhancement") over, say, managing one instance of each
controller per thread and managing its state at request boundaries by
setting instance variables.

Regards,
Martin

[Pascal Voitot Dev]

Guillaume will explain it better than me but those static variables are not real static and as you said they are enhanced into threadlocal variables.
Moreover the stateless design removes any problem of synchronization or thread safety linked to those horrible stateful beans. IMO, Stateless is the best design in >90% of the cases.
For the choice, I let Guillaume or other people from Play! team answer to you but I find this design quite smart, light and efficient ;)

Pascal

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.

[Martin Aspeli]

Hi,

On Jan 8, 5:35 pm, Pascal Voitot Dev <pascal.voitot....@gmail.com>
wrote:

> Guillaume will explain it better than me but those static variables are not
> real static and as you said they are enhanced into threadlocal variables.

Right. I'd like to try to understand how this works, e.g. if I'd like
to follow the same pattern in other projects. Does it rely on byte
code manipulation, for example (which scares me from a debugging
perspective)? Pointers to the source code or docs would be welcome.

I'd be curious to understand why this design was chosen instead of,
say, using singleton instances and passing the request and response as
parameters.

> Moreover the stateless design removes any problem of synchronization or
> thread safety linked to those horrible stateful beans. IMO, Stateless is the
> best design in >90% of the cases.

Couldn't agree more. Stateful web frameworks are almost always
problematic.

Martin

[Guillaume Bort]

Basically we have choosed static methods because we wanted to able to
express routing in a statically typed way:

Application.index() for example.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Guillaume Bort, http://guillaume.bort.fr

For anything work-related, use g...@zenexity.fr; for everything else,
write guillau...@gmail.com

[Martin Aspeli]

On Jan 11, 8:01 pm, Guillaume Bort <guillaume.b...@gmail.com> wrote:
> Basically we have choosedstaticmethods because we wanted to able to

> express routing in a statically typed way:
>
> Application.index() for example.

Interesting. I also think it makes it more obvious that you have to be
stateless in your controllers.

I'm curious if there are any pointers or documentation on how the
thread isolation (the .current() stuff) is implemented? I had a brief
look at the ControllerEnhancer, but I didn't really understand it. ;)

Martin

[Pascal Voitot Dev]

As a Play! user, I don't know any doc about this but the ControllerEnhancer is the right place to look at...
and follow the classes from there!
I don't know any better way ;)
 

[Guillaume Bort]

We simply use ThreadLocal to provided one instance per thread.

http://download.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html

On Wed, Jan 12, 2011 at 9:57 AM, Martin Aspeli <opti...@gmail.com> wrote:
>
>