Hi all,
I'm having a look at how service strategies are used and, hum,
the thing really scares me... it's way to easy, in my opinion, to
forget and clone one object and fall back into a situation where
the code is no more thread safe.
My opinions:
* strategy should not be held as a field, a very small error, a
mis-synchronization and you're doomed;
* since Spring is able to serve stuff as prototypes, why not let
it do the job?
Cheers
Andrea
aaime@anonymised.com ha scritto:
Hi all,
I'm having a look at how service strategies are used and, hum,
the thing really scares me... it's way to easy, in my opinion, to
forget and clone one object and fall back into a situation where
the code is no more thread safe.
My opinions:
* strategy should not be held as a field, a very small error, a
mis-synchronization and you're doomed;
* since Spring is able to serve stuff as prototypes, why not let
it do the job?
In the meantime, I've removed strategy from the fields of AbstractService and create one
for each request, geoserver still bombs with OOM , but takes longer to do so.
(changes are only on my pc now)
Cheers
Andrea
aaime@anonymised.com wrote:
Hi all,
I'm having a look at how service strategies are used and, hum,
the thing really scares me... it's way to easy, in my opinion, to
forget and clone one object and fall back into a situation where
the code is no more thread safe.
My opinions:
* strategy should not be held as a field, a very small error, a
mis-synchronization and you're doomed
interesting ...
* since Spring is able to serve stuff as prototypes, why not let
it do the job?
Bleah, gotta translate that for the spring impaired.
So in terms of making the library easier we could pass this in as a parameter, but spring probably has some tricks here. My guess would be that we would create the strategy object by prototype (ie clone) and pass it in? Or have spring create the context we operate in ...
Cheers,
Jody
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Jody Garnett ha scritto:
aaime@anonymised.com wrote:
Hi all,
I'm having a look at how service strategies are used and, hum,
the thing really scares me... it's way to easy, in my opinion, to
forget and clone one object and fall back into a situation where
the code is no more thread safe.
My opinions:
* strategy should not be held as a field, a very small error, a
mis-synchronization and you're doomed
interesting ...
I'd say, obvious... never hold a mutable field in a class that's supposed to be thread safe,
* since Spring is able to serve stuff as prototypes, why not let
it do the job?
Bleah, gotta translate that for the spring impaired.
When you declare a bean in the spring context, it's a singleton by default, that is, you'll
get the same instance every time you ask for it. Unless you declare it to be a "prototype",
in this case every time you get the bean from the context you'll get a new instance.
Cheers
Andrea
aaime@anonymised.com wrote:
Jody Garnett ha scritto:
aaime@anonymised.com wrote:
Hi all,
I'm having a look at how service strategies are used and, hum,
the thing really scares me... it's way to easy, in my opinion, to
forget and clone one object and fall back into a situation where
the code is no more thread safe.
My opinions:
* strategy should not be held as a field, a very small error, a
mis-synchronization and you're doomed
interesting ...
I'd say, obvious... never hold a mutable field in a class that's
supposed to be thread safe,* since Spring is able to serve stuff as prototypes, why not let
it do the job?
Bleah, gotta translate that for the spring impaired.
When you declare a bean in the spring context, it's a singleton by
default, that is, you'll
get the same instance every time you ask for it. Unless you declare it
to be a "prototype",
in this case every time you get the bean from the context you'll get a
new instance.
Yup, this is nice, its a nice way to deal with operations as well, not
have to worry about making them thread safe.
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel!DSPAM:1004,452c048b56567785049143!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
I'd say, obvious... never hold a mutable field in a class that's supposed to be thread safe,
* since Spring is able to serve stuff as prototypes, why not let
it do the job?
Bleah, gotta translate that for the spring impaired.
When you declare a bean in the spring context, it's a singleton by default, that is, you'll
get the same instance every time you ask for it. Unless you declare it to be a "prototype",
in this case every time you get the bean from the context you'll get a new instance.
Yup, this is nice, its a nice way to deal with operations as well, not
have to worry about making them thread safe.
Well, there's the other side of the coin: you add an "operation" creation each time you need one,
and you create more garbage as well.
Performance implications should be investigated, but if the operation is light to create, and the
actual operation work does generate thousands of short lived objects anyways (say, Features
read from data stores), I guess the extra simplicity of a non thread safe design may save ourself
quite some troubles 
Cheers
Andrea