D
dbeavon
Guest
As you imply, ABL isn't able to take regular shared/exclusive table locks, unlike SQL92 clients. But ABL must *communicate* with any SQL92 clients using intent locks (whether or not there are any actual SQL92 connections to the database is another matter). This communication allows for more advanced transaction isolation options that exist in SQL but not in ABL. For example a SQL client is able to operate in the "serializable" isolation level which essentially prevents a client from ever observing the effects of any other updates by any other clients for the entire duration of the transaction (ie. the SQL client essentially thinks it has an entire database all to itself). Here is some info about standard isolation levels that are available in OE/SQL (stuff that is not specific to Progress/OE): knowledgebase.progress.com/.../20255 The "intent" locks in ABL will conflict with the types of locks that SQL92 takes in order to implement "serializable" isolation. Here is more information about those conflicts: knowledgebase.progress.com/.../P37194 Is there any particular problem that you are trying to solve? We've been seeing those IX locks in promon for years. They shouldn't be the underlying cause for problems (blocking) that arises between ABL clients in the same database. David PS. The first KB article (20255) claims that "range locks" are possible in the OE database. But in practice all I see with "serializable" is that OE (on the SQL side) takes full table locks (shared and exclusive). But you don't have to worry about this if you have no SQL clients, let alone SQL clients using "serializable" isolation.
Continue reading...
Continue reading...