Hi Marty, Just other thing I would like to see in your new books is the treatment of "duplicate form submission". I read about this subject in other books, but they usually use an early implementation made by Struts to solve the problem, and that implementation has synchronization problems. Do you actually include in volume 1 or are you going to include in volume 2 the treatment of this problem? Dani Mazzuca
I guess such kind of a bit advance topics will be included in the volume II... Because I have been asking him a lot questions about the advance topics and he always replies that they are in the volume II... So I can also guess that such kind of concurrency and multi-threading stuffs will be in the volume II. But since I am not the author, I can just guess... :roll:
Because I have been asking him a lot questions about the advance topics and he always replies that they are in the volume II... So I can also guess that such kind of concurrency and multi-threading stuffs will be in the volume II.
Well, I most definitely cover concurrency and multithreading issues in the first volume; you cannot avoid dealing with these issues even in less complex applications. As to handling multiple form submissions, I am not sure I understand the question.
Is it asking what if two submissions occur (from different browser windows) from the same user simultaneously? If so, I address this specifically in the session tracking chapter (synchronize, but use the session object, not "this" as the argument to "synchronized").
Is it asking how to differentiate between two requests by the same user to purchase the same item (ie you want two entries in the shopping cart) from two accidental submissions of a form that purchases an item (ie you want to ignore the second submission)? If so, I admit I haven't thought a lot about how to tell these two cases apart.
As to handling multiple form submissions, I am not sure I understand the question.
Hi Marty, the "duplicate form submission" problem I mentioned before is the one that happens when a user post a request to, for example, debit a credit card, or ship a product, in that moment exists a delay in the network, or whatever, and the user re-submit a second post, by going back and push the button again, or by reloading the blank page before it presents the results. Also it might happen if the user use CTL-N from IE and executes two post "simultaneously", but this is an intentional thing that rarely occurs. What we want to avoid for this critical actions, is that, no two requests are send to the server from the same user, same initial page (of course the user can buy the same product twice or debit the same credit card amount again, but he must re-initiate the sequence of pages to do that). The solution, called "Synchronizer Token", also solves the problem you mentioned first, i.e. two submissions occur (from different browser windows) from the same user simultaneously, however it cannot synchronize over the session object, because the spec doesn't warranty that will use the same session object for all the same user session time, so the idea is to create a new object, put it in the session context, and synchronize over this one (this is warranted to be the same). The solution implemented in the Struts version 1.0 (I believe) has sync problems. I think they corrected it in version 1.1, but I am not sure of that. Anyway, it is a problem that exist in real world WEB appls, and that we should take care when dealing with critical transactions. I think it is not well presented in web books, so I would like to see it in volume 2 (hope so). Any chance? Dani Mazzuca [ November 14, 2003: Message edited by: Dani Mazzuca ]