Hi Kevin, Thanks for answer. I agree that for multipage wizards usually session should be OK. However I can give you two cases from my past projects that are not so easy (developed in java anyway). OK, its not just a wizard - but the problem is the same. a) There were an analytical application that had to display a table data (a few hundreds of rows, 8 columns). Application user had a number of fields that he could change its values - and after submitting - he could see changed database data. However the changes must not be committed until the results was approved by user - he could play with it number of times until the results were ok, than finally - submit it (commit data). In other words - it's kind of "live spreadsheet" based on database. b) There were a simple application for a very small factory that was assisting in scheduling of production. It was really simple however there were a thousands possible product components, one schedule had to contain a few products to be produced. It would be really painful and basically it would make no sense to solve it with session - it would be close to storing a database in session. Even if DB small it's still better that session for storage ;)
Of course both cases could be done with different approach - that our job to find a solution even if its seems there is a dead end :) But the easiest one for me is just using database without commiting transaction (to make sure the data integrity is not broken). Using database for some intermediate storage is just a "design pattern" - it can be done in other ways but this is also a good solution. Please don't underestimate the issue: even in very simple scenario it can be useful: - lest say we have application with tasks and for every task user can add comments - user create task and then create comment - comment is on new page - before he submits comment he decides to CANCEL the whole operation.. I would just rollback data, but without such possibility you need to delete the task.. :) Sometimes leaving task without comment is not so nice - it was created by mistake for wrong project for example... Stupid example but very real use case for 'rollback'. Anyway - it's not a problem for any real current project - I just need to understand how Web2py works to not make any mistake when choosing it for some future project. But I really believe that even if Web2py does not support it - it should be quite easy to make such improvement. But its just intuition - maybe I cannot see some issue... The idea should work like it: - the db object in Web2py should has a property - lets name it "persistent connection". For compatibility it could be set by default to no - in such cases nothing changes. Howevere if you change it to yes you turn on following changes: - when the connection to DB is made the unique ID of the connection is stored in DB object (and in session) - next time when the connection is requested if the ID is not empty - the same connection is restored from the pool - every connection in the pool that should be 'persistent' should also be marked wiht for example session UID - to prevent assignment of it for other session - there should be some kind of very basic garbage collector (or maybe there is something like it???) that should 'free' all persistent connections older than some amount of time Probably I am missing something but it seems it's not so complicated :) To be honest - this kind of persistent connection could be even sometimes faster that the old one - but for the price of resources of course. If you or anyone could explain what I am missing in the idea above ... :) Maybe it's only me but I believe this feature could be very handy for applications dedicated to smaller number of concurrent users.. Or - maybe it does exists in Web2py already ? Thanks Adam
