• 1.  IDS 14 - SBLOB - IFX_ISOLATION_LEVEL and table locked

    Posted 23 days ago
    Edited by Sh To 22 days ago



    We upgraded our development DB to IDS 14,

    and now we have a problem when we manipulate smart blob from the app.

    One of the tables with a smart blob field remains locked.


    The same app/code when connected to another DB server with the same connection string and with exactly the same DB but on Informix 12 works fine.


    If we remove from the application connection string the parameter IFX_ISOLATION_LEVEL=2U, the app works fine with IDS 14.


    Although the default of IFX_ISOLATION_LEVEL parameter is 2, removing only the U doesn't change anything.
    Mistake, It helps.
    So "retain update locks" causes us a lock on IDS14 but not on 12

    3U works fine
    5U locks the table


    Also, this application has some compatibility problem with JAVA 8, so we need to use

    jdbc 3.5 and Java 7 when IDS 14 requires 4.50.1 and 8.

    Do you think it's possible to work with IDS 14 and jdbc 3.5 and Java 7?


    The locking probleme doesn't come from the jdbc and java version. We tried the same app with jdbc 4.50.1 and JAVA 8 and we got the same locking problem.




  • 2.  RE: IDS 14 - SBLOB - IFX_ISOLATION_LEVEL and table locked

    IBM Select
    Posted 22 days ago
    So are you saying those locks persist beyond ... what, transaction commit? Or, if not, what exactly is the issue?
    "retain update locks" causing locks doesn't sound like a problem in itself, but possibly rather like what it should be; so would it be possible that v14 does it right while v12 didn't and you were just living on some misbehavior.  All very speculative, I'd say, and I'd also not know of any change in this respect.

    -> what exact behaviour do you want, with regards to locking and retained update locks?

    Also: what precise v14?  And is this against a standard/primary server, or some updatable secondary instead?

    In any case, if you're suspecting buggy behavior, please raise a support ticket for this.


    Andreas Legner