add request synchronization to the framework?

[Henri Dupre <he...@gmail.com>]

I was wondering if it would be possible/a good idea to add request
synchronization inside the framework to prevent concurrent accesses.
The idea would be to prevent two pages to be rendered concurrently unless
specified (maybe have somekind of page annotation @NonSynchronized). I bet
in 90% of cases this is not a good thing. Of course this can be added as a
servletfilter or other kind of filter, but this would be better at a lower
granularity since the only critical part is the page rendering.
Also it wouldn't be a good idea to prevent concurrent accesses to the asset
service.


Thanks,

Henri.

Re: add request synchronization to the framework?

[Henri Dupre <he...@gmail.com>]

On 6/7/06, Cliff Zhao <zh...@gmail.com> wrote:
>
> Concurrency should be addressed by design.


So what design do you suggest for concurrent accesses to shared objects?
The only designs I know are very heavyweight... You need to manually add
synchronization to all accesses. Even with the new
java.util.concurrentclasses this is still a heavyweight task.,


> Can we let SUN put synchronization on every class because of  the exeption
> in my ASO?


This is not just my exception in my ASO but if you google that topic a
little, you'll find out that this is a very common issue with all web
frameworks. The only known solution that far is to write a
servletrequestfilter.


> Also your sequencing will cause other issues, make users feel your site is
> weird. For example, at one page, the user use the File/New Window in IE to
> open a window and submit a transaction, the transaction may take a while,
> the user goes back to the first page to sumbit another transaction. You
> will
> block the transaction since the other transaction is running? I will be
> very
> unpleased if I were the user.


Yes but in a typical application, I bet that long transaction pages are not
the most common.
Also I don't know about what length of transactions your are thinking but
with our app and a modern server most rendering times are < 100 ms even with
complex db queries. And with <100 ms I'm not sure that a user would even
notice that. Also the page must be quite long if a user has the time to open
File/New Window... And additionally queuing concurrent request will provide
a smoother response when your server will have lots of concurrent users.

That is why there should be a flexible and configurable mecanism. For most
pages you probably want to queue the requests and prevent concurrent
accesses but for some you may want to not use the synchronization.

Maybe having synchronization on by default is a little extreme but having a
flag on each page to synchronize the rendering would be IMO a very valuable
feature.

Anyway I read James post about aegi integration and I'll try to use the same
technique (enhancement workers) to synchronize the page rendering. This
would make such feature pluggable.

Henri.

Re: add request synchronization to the framework?

[Cliff Zhao <zh...@gmail.com>]

Concurrency should be addressed by design.

Can we let SUN put synchronization on every class because of  the exeption
in my ASO?

Also your sequencing will cause other issues, make users feel your site is
weird. For example, at one page, the user use the File/New Window in IE to
open a window and submit a transaction, the transaction may take a while,
the user goes back to the first page to sumbit another transaction. You will
block the transaction since the other transaction is running? I will be very
unpleased if I were the user.

On 6/7/06, Henri Dupre <he...@gmail.com> wrote:
>
> why would you let a single user with one session object execute concurrent
> requests?
> that can cause a lot of funky behavior IMO unless you took it into account
> in your design (I'd be curious to know how many developers are writing
> synchronization code to their ASOs)...
>
> I've seen concurrency exceptions on ArrayList iterators happening because
> of
> the same object being modified by two concurrent requests. On a low load,
> you are probably very unlikely to see that type of behavior but the more
> users you have the more this can happen.
>
> Also queuing concurrent requests can help to lower the load of a server
> http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html
>
>
> On 6/7/06, Cliff Zhao <zh...@gmail.com> wrote:
> >
> > Not a good reason to put synchronization on requests.
> >
> > On 6/6/06, Henri Dupre < henri.dupre@gmail.com> wrote:
> > >
> > > On 6/6/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > >
> > > > Why?
> > >
> > >
> > > Simply to prevent invalid things happening when two pages are
> modifying
> > at
> > > the same time the same ASOs.
> > > I see tons of reasons to prevent that... Writing ASO synchronization
> by
> > > hand
> > > is quite a pain.
> > >
> > > Thanks,
> > >
> > > Henri.
> > >
> > >
> >
> >
>
>
> --
> Thanks,
>
> Henri.
>
>

Re: add request synchronization to the framework?

[Henri Dupre <he...@gmail.com>]

why would you let a single user with one session object execute concurrent
requests?
that can cause a lot of funky behavior IMO unless you took it into account
in your design (I'd be curious to know how many developers are writing
synchronization code to their ASOs)...

I've seen concurrency exceptions on ArrayList iterators happening because of
the same object being modified by two concurrent requests. On a low load,
you are probably very unlikely to see that type of behavior but the more
users you have the more this can happen.

Also queuing concurrent requests can help to lower the load of a server
http://www.onjava.com/pub/a/onjava/2004/03/24/loadcontrol.html


On 6/7/06, Cliff Zhao <zh...@gmail.com> wrote:
>
> Not a good reason to put synchronization on requests.
>
> On 6/6/06, Henri Dupre < henri.dupre@gmail.com> wrote:
> >
> > On 6/6/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > >
> > > Why?
> >
> >
> > Simply to prevent invalid things happening when two pages are modifying
> at
> > the same time the same ASOs.
> > I see tons of reasons to prevent that... Writing ASO synchronization by
> > hand
> > is quite a pain.
> >
> > Thanks,
> >
> > Henri.
> >
> >
>
>


-- 
Thanks,

Henri.

Re: add request synchronization to the framework?

[Cliff Zhao <zh...@gmail.com>]

Not a good reason to put synchronization on requests.

On 6/6/06, Henri Dupre <he...@gmail.com> wrote:
>
> On 6/6/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> > Why?
>
>
> Simply to prevent invalid things happening when two pages are modifying at
> the same time the same ASOs.
> I see tons of reasons to prevent that... Writing ASO synchronization by
> hand
> is quite a pain.
>
> Thanks,
>
> Henri.
>
>

Re: add request synchronization to the framework?

[Henri Dupre <he...@gmail.com>]

On 6/6/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> Why?


Simply to prevent invalid things happening when two pages are modifying at
the same time the same ASOs.
I see tons of reasons to prevent that... Writing ASO synchronization by hand
is quite a pain.

Thanks,

Henri.

Re: add request synchronization to the framework?

[Norbert Sándor <de...@erinors.com>]

Maybe in case of parallel asynchronous AJAX calls a builtin *smart* 
request synchronization would be useful, too...

Norbi

Howard Lewis Ship wrote:
> Why?
>
> On 6/6/06, Henri Dupre <he...@gmail.com> wrote:
>> I was wondering if it would be possible/a good idea to add request
>> synchronization inside the framework to prevent concurrent accesses.
>> The idea would be to prevent two pages to be rendered concurrently 
>> unless
>> specified (maybe have somekind of page annotation @NonSynchronized). 
>> I bet
>> in 90% of cases this is not a good thing. Of course this can be added 
>> as a
>> servletfilter or other kind of filter, but this would be better at a 
>> lower
>> granularity since the only critical part is the page rendering.
>> Also it wouldn't be a good idea to prevent concurrent accesses to the 
>> asset
>> service.
>>
>>
>> Thanks,
>>
>> Henri.
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

Re: add request synchronization to the framework?

[Howard Lewis Ship <hl...@gmail.com>]

Why?

On 6/6/06, Henri Dupre <he...@gmail.com> wrote:
> I was wondering if it would be possible/a good idea to add request
> synchronization inside the framework to prevent concurrent accesses.
> The idea would be to prevent two pages to be rendered concurrently unless
> specified (maybe have somekind of page annotation @NonSynchronized). I bet
> in 90% of cases this is not a good thing. Of course this can be added as a
> servletfilter or other kind of filter, but this would be better at a lower
> granularity since the only critical part is the page rendering.
> Also it wouldn't be a good idea to prevent concurrent accesses to the asset
> service.
>
>
> Thanks,
>
> Henri.
>
>


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org