Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread David Warnock
D, > I often use Firebird and it supports Global Temporary Tables. I wonder > whether that is something designed to resolve Adam's requirement. You > can keep the temporary data even when the connection is lost. > > http://www.firebirdsql.org/rlsnotesh/rlsnotes210.html#rnfb210-globaltemp > > I am

[web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread villas
Lol, we should make a similar comparison of web-frameworks. But joking aside... I often use Firebird and it supports Global Temporary Tables. I wonder whether that is something designed to resolve Adam's requirement. You can keep the temporary data even when the connection is lost. http://www.fi

Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread David Warnock
Hi, > Come on - Python gets a clean slate here! Anyhow, if Adam was the only > shooter and his guns fully locked, his foot should not be at risk. > Just 2 cents. :-) I know, that is why I like the joke. Dave -- Dave Warnock: http://42.blogs.warnock.me.uk Cycling Blog: http://42bikes.warnoc

[web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread villas
>> http://www.netjeff.com/humor/item.cgi?file=shootfoot Come on - Python gets a clean slate here! Anyhow, if Adam was the only shooter and his guns fully locked, his foot should not be at risk. Just 2 cents. :-)

Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread AdamF
Just one thing to make it clear - maybe i shouldn't write mails so fast :) In the ideal word when you start designin your application from scratch - drow all thge diagrams or do it in any other way, traditional or agile - it doesn't matter - but when you start from scratch you can do everything

Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread pbreit
I agree. You don't have to obey your framework but it sure makes things easier.

Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread David Warnock
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 ma

[web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread Massimo Di Pierro
Technically you can ask web2py not to close a db connection and store the connection in cache ram so that another request would pick it up. Yet I cannot recommend anybody doing this. It keeps the database locked, at least the records that are being modified will be locked until commit, resulting in

Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread Fiuk, Adam
Hi Dave, 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

Re: [web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread Dave Warnock
Adam, I am quite surprised that the database administrator was happy with you using a transaction in that way. It goes against the normal practice that a database should never be stalled mid transaction while waiting for user input. If you have a table locking database this will mean the databas

[web2py] Re: question from stackoverflow - DB transactions

2011-03-28 Thread AdamF
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

[web2py] Re: question from stackoverflow - DB transactions

2011-03-26 Thread Kevin Ivarsen
I'm not sure if carrying a transaction across multiple requests is possible, mainly because you can't be assured of getting the same connection to the database across requests. Looking through the code, it does appear to be possible to override the default commit behavior at the end of a succes