Results 1 to 4 of 4
  1. #1
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746

    Unanswered: anyone figured this out yet?

    Very soon my client is going to migrate from 9.5 to 9.7. Good. One of the features I want to use is the currently committed. But not for the whole database. Just a few "selected" queries must come-up with an answer: straight through locks!

    This should be possible. Here IBM DB2 9.7 for Linux, UNIX and Windows Information Center I read

    You can explicitly set the cur_commit configuration parameter to AVAILABLE. Once you set this parameter, you need to explicitly request for currently committed behavior to see the results that are currently committed.

    but is does not say HOW. I assumed that there would be a 5th value to the WITH clause (you know: select ... WITH UR). But that does not seem the case. Google looks away for me here

    Anyone figured it out yet how to force a read-only query to read using cur_commit when you have your db cfg cur_commit set to available?

  2. #2
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    The doc "seems" to suggest it is a bind parameter or specified at statement prepare time (which suggests that use of the feature requires static SQL or dynamically prepared SQL):

    "USE CURRENTLY COMMITTED or WAIT FOR OUTCOME are specified explicitly on the BIND or at statement prepare time."

    Personally, I am very leery of the CURRENTLY COMMITTED, since the log data needed for this may have already been flushed to the active log on disk, or even the archive log. A well written application that finds the currently committed data in the log buffer probably does not need this feature, and a poorly written application will spend a lot of time searching the log files on disk which is going to be pretty slow. By using this feature, it seems to me that one would be encouraging poorly written application code by avoiding -911 errors (which provides immediate feedback to developers that the application is poorly written). I would consider using DB2_EVALUNCOMMITTED, DB2_SKIPDELETED, and DB2_SKIPINSERTED (and WITH UR) instead, and if -911 still occurs, fix the application code.
    Last edited by Marcus_A; 08-25-11 at 09:35.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  3. #3
    Join Date
    Jun 2003
    Location
    Toronto, Canada
    Posts
    5,516
    Provided Answers: 1

  4. #4
    Join Date
    Jan 2009
    Location
    Zoetermeer, Holland
    Posts
    746
    Quote Originally Posted by Marcus_A View Post
    Personally, I am very leery of the CURRENTLY COMMITTED....
    I hear you. I've read more about this issue with the same 'tone' and I agree. That is why we are not going to activate this for the whole database. No, the database must act & react exactly the same as current (=v9.5). But there is 1 query and there quick responce is essential, even if you have to read past lock and come-up with 'old' values as an answer. A lock-wait is not acceptable, just for that 1 query.
    So for that (java/jdbc) connection I am going to override the connection default and I am going to increase the logbufsz to avoid logreads.
    That's the one! Thank you very much.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •