[hibernate-issues] [Hibernate-JIRA] Updated: (HHH-3644) Add support for "WITH UR" isolation clause on DB2

Gail Badner (JIRA) noreply at atlassian.com
Tue Jul 20 17:29:35 EDT 2010


     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gail Badner updated HHH-3644:
-----------------------------

    Affects Version/s: 3.5.3

> Add support for "WITH UR" isolation clause on DB2
> -------------------------------------------------
>
>                 Key: HHH-3644
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3644
>             Project: Hibernate Core
>          Issue Type: Sub-task
>          Components: core
>    Affects Versions: 3.3.1, 3.5.3
>         Environment: HIbernate 3.3.1 / DB2 9.x
>            Reporter: Ricardo Fernandes
>   Original Estimate: 16h
>  Remaining Estimate: 16h
>
> The question is basically the same as Steve's, i.e. to force DB2 to use as few locks as possible on heavy load scenarios. 
> Although some might consider the use of the WITH UR clause a bad approach (since it allows dirty reads), the fact is that there are some cases where this is in fact acceptable, such as computing the total amount of rows of a query (for information purposes) or producing a high-level listing of items with very little detailed info. The bottom line is: if I need to trade performance for extremely accurate data, I surely want to be able to decide when this should happen.
> I've already performed the changes that makes it possible to use both the FOR READ ONLY and the WITH UR clauses and I will be submitting a patch shortly so you can have a look at it. The strategy I've used was basically the following:
> 1. Added two new methods on the Dialect class:
> String getDatabaseReadOnlyString(String sql) - for adding the READ ONLY clause
> String getDirtyReadsString(String sql) - for adding the WITH UR clause
> 2. Changed the Query interface in order to allow the user to say whether he/she wants the query to allow dirty reads:
> Query setAllowDirtyReads(boolean allowDirtyReads);
> 3. Added a default implementation on the AbstractQueryImpl which initializes the flag a false
> 4. Added a similar attribute on the QueryParameters class
> 5. Changed the prepareQueryStatement() method of the Loader class (just after the useLimit part in order:
> a) Ask the dialect for the getDatabaseReadOnlyString() is there are no LockModes set (as did Steve)
> b) Ask the dialect for the getDirtyReadsString() is the queyParameters allows dirty reads.
> All the tests were well succeeded.
> Hope you find these changes, at least, worth looking at.
> Best Regards,
> Ricardo

-- 
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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list