Re: Can't Remove Update Lock

Alireza Assadzadeh wrote: > > Hello, > > We are in the process of designing/implementing a concurrent multiuser > databse system using Informix. > > I have gone through the Informix manuals but it seems that it is > not possible to allow one user to remove an update lock set on row > by another user. The first would lose her/his work, i.e. his/her > transaction should be rolled back either right away or as she/he > attempts to continue her/his work. It should not be possible for the typical user to kill another user's work. The capability you are looking for should not exist. However, there is usually a way around these. I'll describe that at the end of this missive. ;-) > This can be a major draw back. Although under normal circumstances > the second user should not be able to upset the first users > work which included putting an update lock on the row, it would be > usefull to provied this options this option through the application. You will get plenty of argument about that. However, .... > To me personllay this is comming very close to allowing users > to do database administration. Perhaps in the future, they might want > to be able to kill each others database sessions as well. Some people > might even consider this as allowing anarchy. OK, so you understand why Informix (and probably no other vendor) would provide such a capability within the API. > How about trying to delete rows from syslocks table. Probably not > possible. I tried it anyways and could not delete any rows even > with informix user id. The syslocks table is a view on a query that joins several undocumented underlying tables. And you could not delete from the underlying tables either because the ISAM layer recognizes these as pseudo-tables in the sysmaster database and ignores any modification commands. So that's out. > Anyways, our users would like to able to do this and we might > have to create our own version of the syslocks table. OK, you asked for it. I have not tried this, of course. And, of course, you need to cooperation of the DB-Admin person, who should view your request with a very jaundiced eye. Personally, I believe the DB-Admin should jealosly guard the informix password under all circumstances! OK. Write a shell script to do this. The script should be owned by user & group informix and the permissions should be rwsr-xr-x. The idea is that when executed, it runs as user informix. The parameter would be the session ID. The script would run onstat -x, scanning for all transactions belonging to that session ID. Normally, there will be one transaction only but more are possible. It can then on onmode -Z on the transaction ID. If the DB-Admin is gullible enough to allow such a utility to exist, he deserves the resulting anarchy! As mentioned, user informix or user root (or someone with the necessary passwords) would have to create this script. Also recall, I am uncertain if this would work as described. However, user root can pull even cuter schtick. It would merely be an extension of the same idea - a script with rws permissions. In alt.world-destruction.bwahahaha.insane.scientists, I will describe detailed instructions on how to destroy the universe down to the last quantum. Hey! Science is science! >;-) -- -- Jake +-----------------------------------------------------------+ | Diplomacy: The art of getting something off your | | chest without losing your shirt | +------------------------Alfred E. Neuman-------------------+