[Hibernate-JIRA] Created: (HHH-3031) Include "FOR READ ONLY" hint in non-locking DB2 statements
by Steve Finch (JIRA)
Include "FOR READ ONLY" hint in non-locking DB2 statements
----------------------------------------------------------
Key: HHH-3031
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3031
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.5
Environment: 3.2.5, DB2/UDB 8.1+
Reporter: Steve Finch
As per the DB2 documentation:
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.i...
The FOR READ ONLY clause indicates that the result table is read-only and therefore the cursor cannot be referred to in Positioned UPDATE and DELETE statements. FOR FETCH ONLY has the same meaning.
For result tables in which updates and deletes are allowed, specifying FOR READ ONLY (or FOR FETCH ONLY) can possibly improve the performance of FETCH operations by allowing the database manager to do blocking. For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, the database manager might open cursors as if the FOR UPDATE clause were specified. It is recommended, therefore, that the FOR READ ONLY clause be used to improve performance, except in cases where queries will be used in positioned UPDATE or DELETE statements.
A read-only result table must not be referred to in a Positioned UPDATE or DELETE statement, whether it is read-only by nature or specified as FOR READ ONLY (FOR FETCH ONLY).
The aforementioned improvement can be achieved by applying "FOR READ ONLY" when other locking hints are not specified.
Patch to be uploaded soon.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[Hibernate-JIRA] Created: (HHH-6381) using @SecondaryTable with optional=true not handled for joined subclasses (@Inheritance(strategy = InheritanceType.JOINED)
by David Mansfield (JIRA)
using @SecondaryTable with optional=true not handled for joined subclasses (@Inheritance(strategy = InheritanceType.JOINED)
---------------------------------------------------------------------------------------------------------------------------
Key: HHH-6381
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6381
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 4.0.0.Beta2, 3.6.5
Environment: linux, jdk 1.6, hibernate latest from master, oracle 11gr2
Reporter: David Mansfield
When using a @SecondaryTable(name="xx), set to optional using @org.hibernate.annotations.Table(name="xx",optional=true) the documentation states that the secondary table row will only be populated if any one of the properties mapped to the secondary table are not-null. However, this does not work with joined subclasses using the JoinedSubclassEntityPersister. This is because, internally, the boolean which controls "outer joinability" (called isNullableTable) always returns false.
A fix has been tested which will be put into a github pull request.
The fix implements isNullableTable to honor the optional flag.
Unfortunately, there is no way I could find to really test whether the code is working, as it requires examining the SQL generated for various operations. However, I have manually verified the fix. Please look at the output of the JoinedSubclassAndSecondaryTable test, which has been modified as well, to verify the DML statements.
Fix available for 3.6.5 upon request. github pull will be for 4.0 (master).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months