> Expected behavior: > - request1: starts processing, locks pagemap > - request2: comes in: tries to acquire lock > - request2: waits for max N seconds (N being a small number, 1 or 2 > seconds) - request2: sets kill switch for request1 > - request1: first time in wicket managed code: throws Abort > exception, does not commit page hierarchy to pagemap
this step can be quite complex, because at what stage is that? Also long request are very likely not touching any wicket code but those are in queries and so on besides that we must make sure that the object hiearchy and so on is not suddenly in a wrong state. And there are cases that request 1 is still way more important then request 2 and request 2 may never just kill 1. (Request 2 is just a background polling thread of are there any changes) > - request2: starts processing its request
