April 2007 - hibernate-dev - Jboss List Archives

hibernate-oracle9-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

by Steve Ebersole

Hibernate Core 3.2.3.ga has just been released containing mainly minor bugfixes along with the addition of two new identifier generators as well as ceritified suppport for Teradata database. The release can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=40712&package_id=12.... The changelog (for details) is available at http://opensource.atlassian.com/projects/hibernate/secure/ReleaseNote.jsp... Thanks, Steve

19 years

1
0
0 / 0

Re: [jbosscache-dev] Re: JBoss Cache and Hibernate Integration

by Manik Surtani

On 31 Mar 2007, at 19:01, Owen Taylor wrote: > On Fri, 2007-03-16 at 01:23 +0000, Manik Surtani wrote: >> Guys, >> >> I've updated the JIRA [1] and the Javadocs on the Cache interface [2] >> to reflect the new functioning of putForExternalRead(), which I will >> implement by 2.0.0.BETA2. > > This looks like a reasonable specification to me. > >> Just like to clarify that there was also some thought around using >> READ locks for the call when pessimistic locking is used. There was >> also talk about potentially forcing READ_COMMITTED as an isolation >> level for this call if the isolation level used is anything >> stronger. Probably points I should have brought up on the call, but >> are there any thoughts around these? >> >> I'm happy with using a RL instead of a WL simply because we intend to >> only carry out this operation if the node does not exist (see first >> bullet point in the javadoc). Because of this though, I don't see >> how forcing READ_COMMITTED can benefit much, and would just add >> complexity unnecessarily. > > Because the current transaction is suspended, REPEATABLE_READ vs. > READ_COMMITTED seems pretty much irrelevant ... we aren't going > to hold any locks after the operation finishes. > > That, and the fact that the node doesn't already exists, > also means that the difference between write locks and read > locks is pretty small ... the only difference is what happens when > someone else reads between: > > - The update to the node finishes > - We release our locks > > Right? As long as data-structure integrity is preserved, using > a read lock should be OK, but I think the distinction isn't > going to matter much. > > (This is, of course, because JBossCache doesn't acquire locks > across the cluster on a write, but just lets the transaction roll > back on commit in case of conflict. > > If JBossCache did acquire cluster locks on a write, then a write > lock would be much more expensive and avoiding it a big win.) > > - Owen > This is pretty much what I thought. Not included these in the putForExternalRead() spec as a result. Cheers, -- Manik Surtani Lead, JBoss Cache JBoss, a division of Red Hat Email: manik(a)jboss.org Telephone: +44 7786 702 706 MSN: manik(a)surtani.org Yahoo/AIM/Skype: maniksurtani

19 years

1
0
0 / 0

hibernate-mysql-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

hibernate-sqlserver-msjdbc-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

hibernate-pgsql-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

hibernate-hsqldb-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

hibernate-mysql50-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

hibernate-sqlserver-jtds-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

hibernate-sybase-testsuite Build Completed With Testsuite Errors

by jboss-qa-internal＠redhat.com

19 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-dev April 2007