The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Transaction management in web apps?

How do you manage transaction in web apps?
In php, each script contains a connect statement which is of course bad setup. If I will use pconnect or persistent connect how can I control each connection? I've seen plenty of users connected to my dbms but all browser where closed. I want to implement a one to many GUI interface like mostly I did on c/s (desktop) setup. Basically, I want to process all transaction when the user hit/click save button/link. so, I must be operating in autocommit = false. I want to handle the transaction myself. And when the browser is accidentally closed, it must be disconnected to the database as well.
Do I need an application server for this? Do I need to study J2EE? or Is apache/php capable of handling this? My background is client/server (desktop gui). Thanks for any help.
Wednesday, July 13, 2005
I'm not sure there's sufficiently easy way to do this in PHP. Though there certaintly is in Perl and, I assume, Java.

The problem here is being able to keep connection open between requests and retrieve that connection based on its ID that you keep in session data. As far as I know, PHP will close connections at the end of script execution, and using pconnect isn't an option because you don't want connections reused. So you may have to consider writing some kind of proxy or (better) dropping PHP for a more mature environment.
Thursday, July 14, 2005
You could also perform the transaction management outside of the main database tables: store all user input in persistent server memory or temporary database tables, and when you're ready to "commit," move it to the main data tables.
Ryan Send private email
Thursday, July 14, 2005
The approach you describe is not suitable for web apps.

You would generally gather information over several pages, then once everything is together and validated, open a connection, do all the database processing, then close the connection.

Keeping a connection open between requests is fraught with difficulty and should be avoided. Find another approach.

Perhaps "optimistic locking" would be a good search term to find more.
Travelling Steve Send private email
Friday, July 15, 2005
After a bit of thinking in the shower, I figured out this hack: create a pool of host names pointing to the same database server, and open each new connection to a different host name. Then you can use "mysql_pconnect" (or whichever _pconnect your using) to select a certain connection, whose hostname you keep in session data.

Ugly, but should work.
Friday, July 15, 2005
+++Keeping a connection open between requests is fraught with difficulty and should be avoided. Find another approach+++

Not sure what difficulties you're talking about. Caching/pooling open connections is a very common practice. And in the case at hand, you're dealing with a continuous session here, not individual, independent requests, from the workflow standpoint.
Friday, July 15, 2005
HTTP is a steteless protocol, so you cannot have a database transaction (lock, update, unlock) which spans more than one request at a time. Using persistant database connections does NOT allow a transaction to span multiple requests as there is absolutely no guarantee that all requests from the same client will pick up the same database connection previously used by that client. This is NOT a limitation of PHP, it is a limitation of the HTTP protocol.

If you have a transaction which spans several pages, then the way to achieve this in PHP is to store all data in the $_SESSION array until the user presses the SUBMIT button on the last page. Then it is a simple process to take all the data out of the $_SESSION array and write it to the database.

It's easy when you know how.
Tony Marston Send private email
Friday, July 22, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz