Connection readOnly mode is not enforcable after the connect
环境：
WebSphere Server v6.0.22 ， Spring ， Hibernate ，远程 DB2 v8.2 ，JDBC驱动： IBM DB2 JDBC Type 4 driver.
Spring配置文件：
问题：
org.hibernate.util.JDBCExceptionReporter logWarnings Connection readOnly mode is not enforcable after the connection has been established. To enforce a read only connection, set the readOnly data source or connection property.
原因：
the read-only flag is a kind of stepchild in the JDBC spec... Many drivers (and DBMS) don't really support a true read-only transaction. Some do optimize transaction processing, though, so setting the readOnly flag is nevertheless usually worth it.
In your case, the driver simply isn't able to switch the connection to true read-only mode and logs a corresponding warning. This can safely be ignored; your transaction won't get read-only optimizations, but that doesn't hurt.
You could remove the "readOnly" marker from your transaction attribute to avoid the warning. However, "readOnly" also triggers other optimizations, for example it suppresses Hibernate flush attempts for read-only operations, so I recommend to keep those markers and simply ignore the warnings.
I discovered that setting the "readOnly" marker is more than a nice-to-have.
I had a problem http://forum.springframework.org/viewtopic.php?t=4849 when using Spring MVC where despite having validation errors in my onBindAndValidate() method, the bad user entered values bound to my domain objects would get persisted by Hibernate. Turned out that this was because I had the transaction attribute for all service methods without the readOnly marker.
The POJO's are detached in the Spring Form/Command object between requests. When a form is submitted, Spring binds back to these POJO's and since I'm using the Open Session In View (OSIV) pattern, when the request completes the Hibernate transaction commits (at this point the web page is displayed back to the user with validation errors) . The detached objects are brought in context of the Hibernate session before commit takes place.
http://forum.springframework.org/showthread.php?t=12637
WebSphere Server v6.0.22 ， Spring ， Hibernate ，远程 DB2 v8.2 ，JDBC驱动： IBM DB2 JDBC Type 4 driver.
Spring配置文件：
问题：
org.hibernate.util.JDBCExceptionReporter logWarnings Connection readOnly mode is not enforcable after the connection has been established. To enforce a read only connection, set the readOnly data source or connection property.
原因：
the read-only flag is a kind of stepchild in the JDBC spec... Many drivers (and DBMS) don't really support a true read-only transaction. Some do optimize transaction processing, though, so setting the readOnly flag is nevertheless usually worth it.
In your case, the driver simply isn't able to switch the connection to true read-only mode and logs a corresponding warning. This can safely be ignored; your transaction won't get read-only optimizations, but that doesn't hurt.
You could remove the "readOnly" marker from your transaction attribute to avoid the warning. However, "readOnly" also triggers other optimizations, for example it suppresses Hibernate flush attempts for read-only operations, so I recommend to keep those markers and simply ignore the warnings.
I discovered that setting the "readOnly" marker is more than a nice-to-have.
I had a problem http://forum.springframework.org/viewtopic.php?t=4849 when using Spring MVC where despite having validation errors in my onBindAndValidate() method, the bad user entered values bound to my domain objects would get persisted by Hibernate. Turned out that this was because I had the transaction attribute for all service methods without the readOnly marker.
The POJO's are detached in the Spring Form/Command object between requests. When a form is submitted, Spring binds back to these POJO's and since I'm using the Open Session In View (OSIV) pattern, when the request completes the Hibernate transaction commits (at this point the web page is displayed back to the user with validation errors) . The detached objects are brought in context of the Hibernate session before commit takes place.
http://forum.springframework.org/showthread.php?t=12637