MySQL Locks

Question

Hi,
This is quite complicated, and probably I'm making a big mess in many concepts... but can someone help me with this??
All right... I'm using MySQL DB, and it's default table types do not support transactions, so I'm supposed to use table locks instead. There are also InnoDB table types in MySQL which support transactions, but since the server I'm putting all in is still unknown, I don't want to assume it will support InnoDB tables.
Then, when using JDBC API to access this DB, it seems by the documentation that all results are in the ResultSet type. But this representation is in fact a pointer to the DB row, and it pulls up the data just when requested.
For example, if I execute a select statement that returns me 10 rows, one will be read directly from the DB everytime i call the method next.
Is everything correct until now?
OK... the problem is... if I lock the table in order to protect this reading from other threads writings and the rows take some time to process individually, will the table be locked all that long? Or the JDBC implementation does all that for me and I don't even have to use locks? Or this is just an illusion and all the results are read and there is no further concurrency problem - after I release the lock, of course?
I know select, update and other operations are atomic in mysql default tables, but this will be used all over...
One last thing, I'm using MySQL Connector/J 3.0 JDBC driver.
I hope I could describe my doubt...
Thanks

Answer 1

There are also InnoDB table types in MySQL which support
transactions, but since the server I'm putting all in
is still unknown, I don't want to assume it will
support InnoDB tables.If you really need transactions, I think you can safely assume that it is available, since MySQL-Max versions since around 3.23.40+ have supported InnoDB.
Still, if you want to use MyISAM, you could, but individual table locking won't really give you transactional semantics. It may prevent premature dirty reads, but that's all, and it's an extremely expensive way of doing this.
But you may not need to do this, since the MyISAM table manager automatically locks the table when processing a query (so that no inserts or updates can take place while the query is being processed). So you won't get inconsistent results in terms of reading the result of half of an update, for instance.
However, you will never really get transactional semantics unless you lock the entire DB, but that's REALLY nasty.
But this representation is in fact a pointer to the DB
row, and it pulls up the data just when requested.False. MySQL doesn't have anything like DB cursors, so the entire
query result is read into memory as soon as you executeQuery(),
and the next() simply returns you values from memory.
So yes, if you start a query without a restrictive WHERE clause and without a LIMIT clause on a giant table, you'll run out of memory before you can even get the first row.
OK... the problem is... if I lock the table in order
to protect this reading from other threads writings
and the rows take some time to process individually,
will the table be locked all that long? No - see the above. If you're not using explicit locking, the tables being queried will be temporarily locked until the results are generated into the server's memory, and then the locks are released. Then the results are transferred completely to the client's JDBC driver memory, and it then feeds the results on each next() call.
On the other hand, if you lock the DB, you won't get a chance to unlock the DB until all the above steps are completed (i.e. until the last byte of the result set has been sent back to the JDBC driver and processed by it into the ResultSet).
This would make your application nearly unusable.
Or the JDBC implementation does all that for me and I don't
even have to use locks? Well, JDBC won't do this for you. If all you want is a clean query without partial individual-update side-effects, you can get that for free without doing any locking, courtesy of MySQL's MyISAM table manager.
However, if you need transactional semantics (i.e. you want to consider a series of updates or inserts as one transaction, and don't want any other query to see partial results after a subset of those updates), then:
(a) you'll have to do explicit locking, with all the hazards described above,
OR
(b) you'll have to break down and use InnoDB, and ask your users to install MySQL-Max 3.23.latest or 4.0.latest.