glassfish
  1. glassfish
  2. GLASSFISH-14131

Inconsistent pool attributes on GUI and command line

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_ms07
    • Component/s: jca
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      14,131

      Description

      Sorry for the cryptic summary; couldn't think of a good one.

      I have created a JDBC connection pool and associated resource like this:

      I created a connection pool and associated JDBC resource like this:

      asadmin create-jdbc-connection-pool
      --datasourceclassname=com.mysql.jdbc.jdbc2.optional.MysqlDataSource
      --restype=javax.sql.DataSource --description "Test connection pool" --property
      User=scott:Password=tiger:DatabaseName=DB:Port=3306:ServerName=localhost
      "TestConnectionPool"

      asadmin create-jdbc-resource --connectionpoolid "TestConnectionPool"
      --description "Test JDBC resource" jdbc/DB

      Then I navigate to the GUI panel showing the connection pool attributes.

      At the bottom, I see that the Isolation Level is set to Guaranteed (the check
      box is selected). There is a bit of documentation there that says, "All
      connections use same isolation level; requires Transaction Isolation".

      However, the transaction isolation drop down is empty, as I never specified it
      on the command line and do indeed wish to leave it up to the JDBC driver.

      Additionally, you'll note in the command line that I never said anything about
      guarantees of isolation.

      I'm not sure what of all this is intended behavior and what is a bug, but
      thought I'd raise it up.

        Activity

        Hide
        Anissa Lam added a comment -

        I would like the resource team to take a look at the UI to see if what we provided is correct.
        Maybe the inline help need change ? Or maybe UI need change ? Maybe the online help should provide
        more info to ease the confusion ?
        Please add the comment, and we can fix it accordingly.

        Show
        Anissa Lam added a comment - I would like the resource team to take a look at the UI to see if what we provided is correct. Maybe the inline help need change ? Or maybe UI need change ? Maybe the online help should provide more info to ease the confusion ? Please add the comment, and we can fix it accordingly.
        Hide
        sumasri added a comment -

        ->MS7

        Show
        sumasri added a comment - ->MS7
        Hide
        sumasri added a comment -

        ->MS7

        Show
        sumasri added a comment - ->MS7
        Hide
        jthoennes added a comment -

        Hi sumasri,

        I guess you meant _ms07 instead of _b07.

        Cheers, Jörg

        Show
        jthoennes added a comment - Hi sumasri, I guess you meant _ms07 instead of _b07. Cheers, Jörg
        Hide
        sumasri added a comment -

        Yes, I meant MS7. By mistake, I have chosen that.

        Show
        sumasri added a comment - Yes, I meant MS7. By mistake, I have chosen that.
        Hide
        Jagadish added a comment -

        yes, your assumption is correct.
        If no isolation level is specified, it's left to the jdbc driver.

        The default value of "is-isolation-level-guaranteed" is true ie., container will
        book-keep the default isolation level and make sure that the isolation-level is
        indeed the same during connection reuse.
        [Consider the case where an application changes the isolation level and returns
        the connection back to pool. This flag is responsible to give the default
        isolation level during connection creation time.]

        Please refer the docs for more details and their defaults :
        http://docs.sun.com/app/docs/doc/820-7701/create-jdbc-connection-pool-1?l=en&a=view

        "--isolationlevel

        The transaction-isolation-level on the pooled database connections. This
        option does not have a default value. If not specified, the pool operates with
        the default isolation level that the JDBC driver provides. You can set a desired
        isolation level using one of the standard transaction isolation levels:
        read-uncommitted, read-committed, repeatable-read, serializable. Applications
        that change the isolation level on a pooled connection programmatically risk
        polluting the pool. This could lead to program errors.

        --isisolationguaranteed

        This is applicable only when a particular isolation level is specified for
        transaction-isolation-level. The default value is true.

        This option assures that every time a connection is obtained from the pool,
        isolation level is set to the desired value. This could have some performance
        impact on some JDBC drivers. Administrators can set this to false when the
        application does not change --isolationlevel before returning the connection.
        "

        Closing the issue as there is no real defect here.

        Show
        Jagadish added a comment - yes, your assumption is correct. If no isolation level is specified, it's left to the jdbc driver. The default value of "is-isolation-level-guaranteed" is true ie., container will book-keep the default isolation level and make sure that the isolation-level is indeed the same during connection reuse. [Consider the case where an application changes the isolation level and returns the connection back to pool. This flag is responsible to give the default isolation level during connection creation time.] Please refer the docs for more details and their defaults : http://docs.sun.com/app/docs/doc/820-7701/create-jdbc-connection-pool-1?l=en&a=view "--isolationlevel The transaction-isolation-level on the pooled database connections. This option does not have a default value. If not specified, the pool operates with the default isolation level that the JDBC driver provides. You can set a desired isolation level using one of the standard transaction isolation levels: read-uncommitted, read-committed, repeatable-read, serializable. Applications that change the isolation level on a pooled connection programmatically risk polluting the pool. This could lead to program errors. --isisolationguaranteed This is applicable only when a particular isolation level is specified for transaction-isolation-level. The default value is true. This option assures that every time a connection is obtained from the pool, isolation level is set to the desired value. This could have some performance impact on some JDBC drivers. Administrators can set this to false when the application does not change --isolationlevel before returning the connection. " Closing the issue as there is no real defect here.
        Hide
        ljnelson added a comment -

        Hi, yes I understand about the --isolationlevel and --isolationguaranteed
        options. You'll note that I specified neither of them, so --isolationguaranteed
        has a value of true by default. That's fine.

        What threw me was the documentation on the screen. Isolation level shows up
        as being selected, and the documentation under it says this is only valid if an
        isolation level has been selected, which, of course, it hasn't.

        So the documentation makes it look like I've done something wrong, when of
        course I haven't. It looks like there is an inconsistent state on the screen,
        viz. that isolation guaranteed is on, but isolation level hasn't been selected.
        This is in fact a VALID state of affairs, but the doco implies that it is not.
        That's all.

        Show
        ljnelson added a comment - Hi, yes I understand about the --isolationlevel and --isolationguaranteed options. You'll note that I specified neither of them, so --isolationguaranteed has a value of true by default. That's fine. What threw me was the documentation on the screen. Isolation level shows up as being selected, and the documentation under it says this is only valid if an isolation level has been selected, which, of course, it hasn't. So the documentation makes it look like I've done something wrong, when of course I haven't. It looks like there is an inconsistent state on the screen, viz. that isolation guaranteed is on, but isolation level hasn't been selected. This is in fact a VALID state of affairs, but the doco implies that it is not. That's all.

          People

          • Assignee:
            Jagadish
            Reporter:
            ljnelson
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: