db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <fisc...@seitenbau.net>
Subject RE: Objection to deprecate lockTable was: Missing close-operations for Statements
Date Thu, 31 Mar 2005 12:37:12 GMT

Hi Michael,

Other people have already objected, and I have realized that it is not a
good idea and refrained from it.

The reason why I originally considered to remove the methods is the
following: Although this method suggest that there is a way to lock and
unlock tables in a database independent way, in fact there isn't. For
example in oracle, it seems that a lock can only be released by issuing a
commit, which has other side effects. So I do not think this will help much
in making code database independent.

What the methods do aqchieve is that if locking and unlocking works, you do
not have to do it via SQL, which is (from Torque's view) also a good thing.

(Another point which led me to that suggestion was that I thought that
everything which you can do by locking tables can also be done by
serializable transactions.  I realized in the meantime that I was wrong.)

If you have code to improve the adaptors and have not already done so, can
you please open a scarab issue (http://issues.apache.org/scarab/issues).
Request a role as observer (replace the localhost:somePort part in the
"confirm registration email" by issues.apache.org), create a new issue,
upload your patches as unified diffs. AFTER you have uploaded all patches,
save the issue.
If there already exists a scarab issue, can you please mail the issue Id.



"Michael Beier" <mbeier@VPS.DE> schrieb am 31.03.2005 14:04:39:

> Hello Thomas,
> I must say, that i do have objections, as we currently use this method.
> Im not quite sure, but i think, the ID-Generator uses these methods
> too, as the Statement implicates (SELECT next_id FROM); the tablerow
> next_id is only inside the ID-Table.
> This is a bug, which i stated before, but no one seems to have noticed.
> some of the adapters have the false logic (next_id instead of *) in
> there sourcecode, so that you can not use this function in general.
> i changed that localy in my torque code, and we do use this method
> for locking tables in general.
> If this Function will be deleted, wich other way will be there to
> lock a table if not using a DB-Specific PS ?
> This would bring torque a step away from making the javacode
> independent to the sql-code.
> Michael Beier
> vps Video Print Systeme GmbH
> Dipl.-Inf. Michael Beier

To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message