On 3/22/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > On 3/21/08, Andreas Hartmann <[EMAIL PROTECTED]> 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: http://solprovider.net/fieldupdates.html HTH, solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
