The solution is thread safe - as it uses tapestry's own property management. I've yet to see it fail! I'm still cleaning code up so I'll supply it soon. Oh yes, and - I am a cheat - the component is a copy & paste of the original form with about 10-20 lines (spaces included!) of extra code.
On 11/29/05, Ivano <[EMAIL PROTECTED]> wrote: > > Question: does Tap use component pooling, like it does for pages? > When you lock form submission and page visiting does it block other > concurrent accesses from other users to the same page and form? > If your form concurrency's sound and safe, I find it's a really > interesting solution, could you send some code? > > Thanks and goodbye. > > Ivano Pagano > > William Keller wrote: > > >Javascript solution is a good catch all - but I wasn't confident or happy > >just with relying on front end tricks. What' I've done, is very simple. I > >re-wrote the Form component. In the form component, there is a persistent > >Hashtable property that stores a user's session id and page name (this > gets > >around page recorder errors). > >Before the listener is 'triggered', we: > > > >* lock > >* execute listener > >* in a finally block, we unlock. > > > >This not only works in blocking multiple submits, but it also prevents > the > >user from visiting the submitting page in the event of a > >looooooooooooooooong transaction (as is in our case). This new Form > >component must implement PageRenderListener and implement pageBeginRender > to > >check the locked condition. The same goes for prepareForRender. Finally, > for > >sanity - we check the lock condition before locking. This may not be > >necessary, but it works for me! > >Also - what does the lock check do? It throws a well known exception that > >you can handled by overriding BaseEngine's 'activateException'. > > > >Hope this helps! > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
