lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From solprovi...@apache.org
Subject Re: Viewing meta data creates continuation
Date Sun, 23 Mar 2008 02:42:37 GMT
On 3/22/08, Andreas Hartmann <andreas@apache.org> wrote:
> solprovider@apache.org schrieb:
> > On 3/21/08, Andreas Hartmann <andreas@apache.org> wrote:
>  >>  everytime the meta data tab is requested, a continuation is created.
>  >>  Even if you modify and save the meta data, another continuation is
>  >>  created, because the screen is displayed again. This behaviour
>  >>  unnecessarily increases memory consumption.
>  >>
>  >>  I see two options to avoid the problem:
>  >>  1. Don't create continuations
>  >>  2. Separate "modify meta-data" usecase
>  > My vote would be for #1 because I have psychoses about locking systems
>  > and limited-duration server-based data storage.
> If we submit only a single value (e.g. using AJAX or by comparing old
>  and new values), #1 might be OK. Mabye we could send the original value
>  together with the new value so that the server can check for concurrent
>  changes and output a warning (avoid read-write conflicts) without
>  server-side locking.
>  > If using #2, do not add clicks.  AJAX needs neither the submit button
>  > nor "edit" links.  Just use onChange() and similar events to trigger
>  > the sendInformation().
> Won't that generate a lot of traffic? Or is it easy to add a timer which
>  submits only if no change happened e.g. for 1 second? Personally, I
>  don't mind to add at least a "Save" button. Hitting the return key
>  should also work.

Normal overhead is one POST request containing all fields.  AJAX
overhead is a POST request containing one field and its old value for
each change.

Sending each field when changed (and only the field that has changed)
may reduce traffic compared to submitting the entire page depending on
user behavior and the data.  A user editing each field three times
would save bandwidth by submitting everything once when finished.  A
user changing only three of twenty fields and editing each field only
once would save bandwidth by sending the individual fields.

Bandwidth is a minor consideration.  This discussion is about patching
communication methods to overcome the limitations of the model.
Function before performance.  Besides, metadata is edited so
infrequently that performance only matters when the server is
corrupted (like the multiple-continuations memory leak you are trying
to solve.)

>  > Even a monitor thread checking every 5 seconds
>  > to test for changed fields is better than adding clicks.  (I also have
>  > a psychosis about creating listener threads for trigger events.)
> I don't quite understand the bit about the listener threads - would you
>  mind elaborating? Thanks a lot!

Sorry, my mistake.  My last sentence should have been "...about using
monitor threads to handle triggered events" like having a schedule
checking for changed fields (= monitor thread) when the action
changing the field should trigger the event.

Here is a demonstration:


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

View raw message