Adam, Thanks for the answer and hints, I will analyze it deeper later, but to > answer you now - please make sure you know the person before you suggest him > buying a book ;) I am working currently on RDBMS with terrabytes of data, up > to 2-3 thousands concurrent users and I have to live with many different > issues. Including locking for example. I am not allowed to send you design > documents since its confidential, >
I am still amazed that with that size of data and number of users the idea of leaving a transaction open while you wait for user interaction seems a good solution. As for my knowledge I left the IT industry for a complete career change 5.5 years ago, before that I worked professionally with dbms and coding for some 25 years before that (including Java and Oracle). Of course I shouldn't see your design documents. However, I suggest that persisting a database connection across multiple http calls (remembering that http is inherently stateless) and across user input is still unlikely to be a good design. There are too many fragile elements in the design. Just 3 examples - it raises scaling issues. eg the restrictions on load balancing Web2py. - it raises usability issues (I get a phone call, my 10 minutes expires and I lose my work) - it raises fragile coding issues (somewhere in a class someone adds an update of a related table and suddenly you are locking an important row such as an inventory item, a customer, ...) Of course - there might be resource or performance issue however it also was > analyzed and even consulted in one particular case with Oracle support to > make sure they do not see any problems here > Excuse me if I don't bow down in front of Oracle support :-) > Every use case must be analyzed seperately. In many cases - yes, 100% > right, user input should never be allowed in the middle of the session. But > it's not the rule... > Seriously, show me where I am wrong. Give me some examples of SQL guru's suggesting that it is a good design to keep a transaction alive across multiple http calls with user input required between them. To be more positive, if the design decision is fixed then why not consider a small long running server process that holds the transaction (it can handle time-outs, keep alive etc). Let the web2py application make it's calls to that server process. > Anyway - you have 100% rights to dislike and criticize my design, I respect > it :) But I don't think this is the real issue - so let's concentrate on > Web2py. If you and others don't like the idea of 'persistent transactions' > that means that for this kind of design I don't use Web2py, thats all. I > will stick to Java where the language and framework doesn't force me how I > should design the solution :) > I always prefer tools that obey me - instead of tools that I have to obey > ;) > First, I am a web2py newbie so have little influence over the design & implementation (hence my focus has been much more generic than limited to web2py* *I don't think this is any better idea in java). Second, Massimo has indicated how you could do what you want Third, given all the constraints your design has to impose for it to work (only inserts, whole areas of the application locked to one user, 10 minute timeout etc). I suggest that this does not make a good candidate for inclusion as a standard supported technique by web2y. I am reminded of the joke which compares the way programming languages support shooting yourself in the foot eg http://www.netjeff.com/humor/item.cgi?file=shootfoot To my mind web2py has this about right in saying this is a bad idea, we will not support it automatically, if you really want to do this then it is possible and here is how you could do it but don't complain afterwards :-) All the best Dave -- Dave Warnock: http://42.blogs.warnock.me.uk Cycling Blog: http://42bikes.warnock.me.uk
