Scribit Mariano Montone dies 27/06/2007 hora 13:12: > I've been developing web applications so far, so I'll be describing a > web UI.
I've been making web apps too, mostly. I don't think it's web specific, but it's probably worse in web UIs, because they have a much worse latency than GUIs running locally. > There are cases in which a user wants to perform several operations in > a transactional way. Do you have examples? The only cases where my own apps needed several pages for an operation were creation operation, IIRC. On the other hand, there is at least one famous example, namely most online shops checkout operation. On Amazon, ISTR you go through 3 or 4 pages to checkout. I never tried to update my cart while doing that. I wonder how it behaves. > The problem is that long transactions are not supported by today > databases. When I say long transactions I mean the ones that have a > lifetime related to the user interaction with the application. The good thing may be that the semantics and some practical implication are msotly the same. The interactions of long transactions may be radically different than of extremely short ones, though. They may fail more, and be slower to restart. It would be fairly important to identify what transactions can be silently restarted and which need user input again. When this is needed, it will take a huge time for the new transaction to be committed, compared to when it is automatically restarted. > The consecuence is that the user may have performed operations based > on some knowleadge that will not hold if the transaction gets > restarted silently. That would be a bug. Transactions that are restarted are code, and this code makes decisions based on data it sees. In STM, for example, the side-effects of a restarted transaction could be different from those of its first run. > The application is not aware of that and the user is not warned of > that (the new query results are never displayed again to the user). The application must be aware of what data was read to build the UI from which the user made decisions. > The algorithm would be similar to the one used for STM [1]. It doesn't > lock records and deadlock cannot occur. There is a huge difference with STM, in that there is a huge latency in our case. This opens up a vulnerability on denial of service. If an hostile agent manages to modify some data often enough, it can prevent the user from committing his own modifications. This means that locking should be made available to the user, so that it can protect himself from that (of course, that means he can DoS others, and you have to deal with that also...). > 1) Does what I am saying make any sense? :) Definitely. That could be a good step towards making some applications more robust. > 2) How do you attack these problems in your applications? By ignoring them. ;-) Now that I think of it, I'm pretty sure many of my applications are vulnerable when multiple users make overlapping modifications. This means some modifications will be silently overwritten, sometimes making the whole data set inconsistent. That's an interesting issue, BTW. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
