I did some web+dB work with MySQL and python. The MySQL daemon that actually did the work on the tables allowed table-locking to various degrees -- one way to maintain synch. Other dB's allow transaction-locking where a group of statements are synchronized, and either all occur together and succeed, or fail gracefully resulting in a no-op.
One of the reasons dB's get used so much for web-based app's is that the HTTP servers generally don't have a synch mechanism -- the HTTP daemon sees an incoming request, forks itself (into process or thread), and hunkers down again to wait for the next request. The child processes/threads, if they need to synch, must implement that synch externally to the HTTP server... and thus often rely on standard dB locking capabilities to do so.
So I think it's probably more important to initially investigate the dB you're using (and the JDBC method of invoking that dB's capabilities) rather than first looking at JDBC and Java.
(depending on which DBM you are using - mysql doesn't do any of this, but I think everything else does, so Postgres, Oracle, Informix, Sybase, etc. are all good)
Yes! All real databases support table locking, and most support row locking. You want to put the lock in the database, because databases are meant to be used by 10 gajillion programs at once, so even if you synchronize the java, different java processes could still stomp on each other. There are 2 ways of doing this - you can either do it with Java objects and methods, or you can do it using SQL. I recommend the SQL approach, but that's just a personal preference.
The words to search for are "row locking" and "table locking". WAIT!!! NO THAT'S NOT WHAT YOU WANT AT ALL. IGNORE EVERYTHING I HAVE JUST SAID
( ... )
Well - that depends. MySQL is smart enough not to have concurrent writes to the same table mess thigns up, but if you have a bunch of operations that you need to be atomic because stopping in the middle would leave things in a bad way, MySQL can't really do that.*
If your program will only be run one instance at a time and/or it doesn't have any multi-operation sequences and/or they are naturally pretty quick operations, then the ostrich algorithm will probably work just fine.
If you want transactions and libre, I recommend PostgreSQL. It's slower than MySQL, but provides data guarantees and transactions and the like.
* Newer versions claim to be able to, but that's still beta stuff.
thank youmaxemulienSeptember 22 2003, 12:04:45 UTC
I suspect the transaction approach is what I'm looking for. My first shot will be to use Java for the transactions, which should spare me some of the searching through documentation for now.
Comments 14
One of the reasons dB's get used so much for web-based app's is that the HTTP servers generally don't have a synch mechanism -- the HTTP daemon sees an incoming request, forks itself (into process or thread), and hunkers down again to wait for the next request. The child processes/threads, if they need to synch, must implement that synch externally to the HTTP server... and thus often rely on standard dB locking capabilities to do so.
So I think it's probably more important to initially investigate the dB you're using (and the JDBC method of invoking that dB's capabilities) rather than first looking at JDBC and Java.
Reply
Yes! All real databases support table locking, and most support row locking. You want to put the lock in the database, because databases are meant to be used by 10 gajillion programs at once, so even if you synchronize the java, different java processes could still stomp on each other. There are 2 ways of doing this - you can either do it with Java objects and methods, or you can do it using SQL. I recommend the SQL approach, but that's just a personal preference.
The words to search for are "row locking" and "table locking". WAIT!!! NO THAT'S NOT WHAT YOU WANT AT ALL. IGNORE EVERYTHING I HAVE JUST SAID ( ... )
Reply
It doesn't? Ummm... shit; my software must just be lucky...
Reply
If your program will only be run one instance at a time and/or it doesn't have any multi-operation sequences and/or they are naturally pretty quick operations, then the ostrich algorithm will probably work just fine.
If you want transactions and libre, I recommend PostgreSQL. It's slower than MySQL, but provides data guarantees and transactions and the like.
* Newer versions claim to be able to, but that's still beta stuff.
Reply
Reply
Leave a comment