The news popped up at CRN, and the discussion talked about a mysterious new feature called "record level locking". No one could understand what this is... It seems to be row level locking, but we all know IDS has this since its beginning. Some insiders, like Madison Pruet and Christine Normille said that this could be one of several features:
- Last commited concurrency
- Label based access control (LBAC)
- Optimistic concurrency
Last committed concurrency:
- As we know, we have four isolation levels currently in IDS. Dirty read, Committed read, Cursor stability and Repeatable read. The most uses are probably Dirty read and Committed read (the default for logging databases). We also know the implications of both of these levels. In dirty read mode we won't block or get errors when reading a row that it's being updated by other session, but the payback is that we will read "uncommitted data", that may well be rolled back or may be inconsistent.
In committed read we only access committed and consistent data but we will stop or wait whenever we need to read a row that is being updated.
So, the "last committed concurrency" will be another isolation level with the following behavior: Whenever we hit a locked row, we will read (without blocking) the previous image. A perfectly committed and consistent image, although possibly this data will change immediately. As many may know this is apparently very similar to what Oracle and Postgres do (the well known "writers don't block readers"). Nice... to use it we'll probably only have to issue some SET ISOLATION LEVEL TO LAST COMMITTED.... command
Label based access control (LBAC):
- This seems another interesting feature... but there isn't much info about it for now. Currently we can GRANT/REVOKE privileges to allow users to access certain columns. What this will provide is a mechanism of allowing access based on certain conditions. e.g.: we might restrict access to data from the user department, or for users of a specific region. The way to do this seems a bit complex, and I don't have any information on how IDS will implement it. If you're curious you can check a tutorial for DB2. I'd say the IDS implementation should be very similar.
Optimistic concurrency:
- This is another feature without much info around it. By definition optimistic concurrency is a method of controlling concurrent access to data based on the idea that most accesses (transactions) don't conflict with each other. As such, a session that wants to update a row won't lock it. At commit time the system will check that the row hasn't changed from the beginning of the transaction. If it has, the commit can't be done... This will work, and will be much more efficient that the normal lock mechanism if the assumption (the transactions won't conflict) is true. If it's false, it will perform worse than the locking mechanism, and will cause much more applications problems
Given this brief explanation about the talked about new features we can wonder if and when this will appear on the product, and what more is yet to come. There are no answers, or put in another way, no one can give any answers at this time, although the answers exist. Like any other software vendor, IBM can't and obviously won't compromise on new functionalities that may have to be delayed. But whether these and many other planned features will appear on the next version (code name cheetah) or only in the second yet to come version, or in some intermediate releases, one think is clear: IBM is putting a lot of developing resources behind IDS, and I can't see any reasons to fear about the future of the product. Ever since acquisition, customers have been worried (mainly because of FUD coming from the competitors), and watching every move from IBM. And one thing is obvious: Every IDS version that came out from IBM included significant improvements and a bunch of new features (9.4 and 10.00). By "significant" I mean features that implicate some structural changes and big code changes.
If you want to take a look at the discussion on the comp.databases.informix newsgroup and you don't have easy access to a news server/software you can check the posts on Google groups.
I really hope to get back to this subject on Cheetah new features. And by the way, "cheetah" is the fastest running animal on earth... It's fast, because every part of its body is adapted in some way to help it run faster... That's how an RDBMS should be built :)
No comments:
Post a Comment