You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jochen Kemnade <jo...@eddyson.de> on 2014/05/02 10:35:35 UTC
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Hi,
Am 24.04.2014 13:53, schrieb Jochen Kemnade:
> But, to lessen the effect, couldn't we check if the attribute is
> immutable and downgrade the write lock in that case?
or maybe we should just add a symbol to toggle support for persisting
mutable values in the session, defaulting to true of course.
Then we'd have the problem of knowing which classes are immutable. We
could easily solve this via a service though. Something along the lines of
contributeImmutableClasses(Configuration<Class> c){
c.add(String.class);
c.add(Integer.class);
// and then, in a custom module
c.add(MyCustomImmutableClass.class);
}
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <ke...@gmail.com>.
Hi,
I created TAP5-2357 so this doesn't get lost.
Jochen
Am 06.06.2014 07:06, schrieb Howard Lewis Ship:
> I'll try to find time …
>
> On Tuesday, June 3, 2014, Jochen Kemnade <jo...@eddyson.de> wrote:
>
>> Howard, could you please comment on the patch since you introduced the
>> session locking?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Howard Lewis Ship <hl...@gmail.com>.
I'll try to find time …
On Tuesday, June 3, 2014, Jochen Kemnade <jo...@eddyson.de> wrote:
> Howard, could you please comment on the patch since you introduced the
> session locking?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
@hlship
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <jo...@eddyson.de>.
Howard, could you please comment on the patch since you introduced the
session locking?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <ke...@gmail.com>.
Morning,
new patch is attached. It changes the name of the new service from
ObjectMutabilityAnalyzer to MutabilityAnalyzer and correctly keeps the
write lock locked when an attribute is written into the session and an
immutable object is read afterward.
Any more comments?
Jochen
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <ke...@gmail.com>.
Am 28.05.2014 21:32, schrieb Bob Harner:
> Might I suggest MutabilityAnalyzer instead of ObjectMutabilityAnalyzer?
Sure, who says sed can't be used on a patch... ;-)
> On Wed, May 28, 2014 at 3:20 PM, Jochen Kemnade <ke...@gmail.com> wrote:
>> Hi,
>>
>> here we go, new patch. Please comment.
>> I guess most of the changes are quite easily understandable if you've
>> been following this thread, but feel free to ask questions or press me
>> to write more/better comments if anything is unclear. ;-)
>>
>> Jochen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Bob Harner <bo...@gmail.com>.
Might I suggest MutabilityAnalyzer instead of ObjectMutabilityAnalyzer?
On Wed, May 28, 2014 at 3:20 PM, Jochen Kemnade <ke...@gmail.com> wrote:
> Hi,
>
> here we go, new patch. Please comment.
> I guess most of the changes are quite easily understandable if you've
> been following this thread, but feel free to ask questions or press me
> to write more/better comments if anything is unclear. ;-)
>
> Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <ke...@gmail.com>.
Hi,
here we go, new patch. Please comment.
I guess most of the changes are quite easily understandable if you've
been following this thread, but feel free to ask questions or press me
to write more/better comments if anything is unclear. ;-)
Jochen
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 28 May 2014 11:36:31 -0300, Jochen Kemnade
<jo...@eddyson.de> wrote:
> Hi,
>
> Am 28.05.2014 16:05, schrieb Thiago H de Paula Figueiredo:
>> I guess it'll be rare to actually analyze the mutability of an object
>> and not of its class, but I can't see why not. :)
>
> I don't mean to split hairs, but we always want to determine the
> mutability of an object. Mostly, we'll use its class to do that however.
Agreed
>> [...] I see no need to put the Tapestry-provided first.
>
> Alright, I'll just put one first that handles null, so we don't have to
> bother with that later.
Nice catch. Null is immutable. :D
> Btw., if we use isImmutable(Object) instead of isMutable(Object) (why do
> I always start writing the opening paren before the func... err.. method
> name),
Lisp feelings? :P
> we can even use a Chain of Command (remember, true will exit the chain).
> :-)
Definitely a chain of command. :)
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <jo...@eddyson.de>.
Hi,
Am 28.05.2014 16:05, schrieb Thiago H de Paula Figueiredo:
> I guess it'll be rare to actually analyze the mutability of an object
> and not of its class, but I can't see why not. :)
I don't mean to split hairs, but we always want to determine the
mutability of an object. Mostly, we'll use its class to do that however.
> [...] I see no need to put the Tapestry-provided first.
Alright, I'll just put one first that handles null, so we don't have to
bother with that later.
Btw., if we use isImmutable(Object) instead of isMutable(Object) (why do
I always start writing the opening paren before the func... err.. method
name), we can even use a Chain of Command (remember, true will exit the
chain). :-)
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 28 May 2014 10:45:06 -0300, Jochen Kemnade
<jo...@eddyson.de> wrote:
> Am 28.05.2014 15:32, schrieb Jochen Kemnade:
>> How about ClassMutabilityAnalyzer if we really want to use it for that
>> single
>> purpose only?
>
> Or rather ObjectMutabilityAnalyzer (because we actually want to
> determine if an *Object* is immutable) and an OrderedConfiguration, so
> we can put fast analyzers first.
I guess it'll be rare to actually analyze the mutability of an object and
not of its class, but I can't see why not. :) Please go ahead. ;) I like
the name very much, as it's descriptive and follows the pattern used in
similar services.
Regarding putting the fast (also generic and class-based ones) first or
last, we usually put them last, so the user-contributed ones get used even
if you don't use an ordering constraint, and most people don't know or
forget about it, then the Tapestry-provided ones get called first and the
user provided are never actually invoked. Anyway, even the object-based
ones, which I guess Tapestry will provide none, will be quite fast
already, so I see no need to put the Tapestry-provided first.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <jo...@eddyson.de>.
Am 28.05.2014 15:32, schrieb Jochen Kemnade:
> How about ClassMutabilityAnalyzer if we really want to use it for that single
> purpose only?
Or rather ObjectMutabilityAnalyzer (because we actually want to
determine if an *Object* is immutable) and an OrderedConfiguration, so
we can put fast analyzers first.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <jo...@eddyson.de>.
Hi,
Am 28.05.2014 14:25, schrieb Thiago H de Paula Figueiredo:
>> I'm still undecided how to handle this issue. To get started, I created
>> and attached a simple patch that downgrades the write lock to a read
>> lock if the attribute's class is a String, a primitive wrapper type or
>> has the ImmutableSessionPersistedObject annotation.
>> This is of course not very flexible but should work in a lot of
>> situations. And we can always extend the list of immutable classes later.
>> However, if we want a more flexible approach, I guess the best way to go
>> would be a SessionPersistedObjectAnalyzer2 interface, with an added
>> boolean isMutable(T sessionPersistedObject) method.
>
> I'd keep SessionPersistedObjectAnalyzer as it is and create a separate
> service, let's say ImmutableClassService, with a single method
> isMutable(Class clasz), which would be basically a collection of Class
> instances received from distributed configuration. This new service
> could be even used by other code that could benefit from knowing which
> classes have immutable instances.
Yes, that's what I proposed earlier. I've come to thinking that it might
be overkill to create a service for just that tiny purpose and that it
might become hard to keep the overview over all services over time if we
did that too often. And I thought that SessionPersistedObjectAnalyzer
might be the right place to add the method. But I'll have a go at that
and see how bad it gets. ;-)
Only, I don't like the name ImmutableClassService because it doesn't
tell you straight away what the service is for. How about
ClassMutabilityAnalyzer if we really want to use it for that single
purpose only?
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 28 May 2014 07:52:31 -0300, Jochen Kemnade
<jo...@eddyson.de> wrote:
> Hi,
Hi!
> I'm still undecided how to handle this issue. To get started, I created
> and attached a simple patch that downgrades the write lock to a read
> lock if the attribute's class is a String, a primitive wrapper type or
> has the ImmutableSessionPersistedObject annotation.
> This is of course not very flexible but should work in a lot of
> situations. And we can always extend the list of immutable classes later.
> However, if we want a more flexible approach, I guess the best way to go
> would be a SessionPersistedObjectAnalyzer2 interface, with an added
> boolean isMutable(T sessionPersistedObject) method.
I'd keep SessionPersistedObjectAnalyzer as it is and create a separate
service, let's say ImmutableClassService, with a single method
isMutable(Class clasz), which would be basically a collection of Class
instances received from distributed configuration. This new service could
be even used by other code that could benefit from knowing which classes
have immutable instances.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <jo...@eddyson.de>.
Hi,
Am 07.05.2014 22:44, schrieb Thiago H de Paula Figueiredo:
> On Wed, 07 May 2014 03:41:46 -0300, Jochen Kemnade
> <jo...@eddyson.de> wrote:
>
>> Hi,
>
> Hi!
>
>> I just re-discovered the ImmutableSessionPersistedObject annotation.
>> Maybe we can leverage that?
>
> I think we could use both approaches, as we cannot add the annotation to
> classes we don't own.
>
I'm still undecided how to handle this issue. To get started, I created
and attached a simple patch that downgrades the write lock to a read
lock if the attribute's class is a String, a primitive wrapper type or
has the ImmutableSessionPersistedObject annotation.
This is of course not very flexible but should work in a lot of
situations. And we can always extend the list of immutable classes later.
However, if we want a more flexible approach, I guess the best way to go
would be a SessionPersistedObjectAnalyzer2 interface, with an added
boolean isMutable(T sessionPersistedObject) method.
Any thoughts?
Jochen
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Wed, 07 May 2014 03:41:46 -0300, Jochen Kemnade
<jo...@eddyson.de> wrote:
> Hi,
Hi!
> I just re-discovered the ImmutableSessionPersistedObject annotation.
> Maybe we can leverage that?
I think we could use both approaches, as we cannot add the annotation to
classes we don't own.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: [2/2] git commit: TAP5-2049: Use a lock when reading/updating
HttpSession attributes - Add a symbol to deactivate the session locking logic
Posted by Jochen Kemnade <jo...@eddyson.de>.
Hi,
Am 02.05.2014 10:35, schrieb Jochen Kemnade:
> Am 24.04.2014 13:53, schrieb Jochen Kemnade:
>> But, to lessen the effect, couldn't we check if the attribute is
>> immutable and downgrade the write lock in that case?
>
> or maybe we should just add a symbol to toggle support for persisting
> mutable values in the session, defaulting to true of course.
> Then we'd have the problem of knowing which classes are immutable. We
> could easily solve this via a service though. Something along the lines of
>
> contributeImmutableClasses(Configuration<Class> c){
> c.add(String.class);
> c.add(Integer.class);
> // and then, in a custom module
> c.add(MyCustomImmutableClass.class);
> }
I just re-discovered the ImmutableSessionPersistedObject annotation.
Maybe we can leverage that?
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org