January 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2214) SQLStateConverter chooses wrong JDBCException: Locks and MySQL

by Christian Gruber (JIRA)

SQLStateConverter chooses wrong JDBCException: Locks and MySQL -------------------------------------------------------------- Key: HHH-2214 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2214 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0 MySQL 4.1.14 and 5.0.24 Reporter: Christian Gruber Priority: Minor In MySQL, there are (at least) two SQL states that signal some problems with locks: 40001 and 41000. Currently, the SQLStateConverter maps the state 40001 to a LockAcquisitionException and the state 41000 to a GenericJDBCException. Could the state 41000 also be mapped to a LockAcquisitionException, or can this cause problems with other databases? Here the corresponding JDBC exception: java.sql.SQLException: Deadlock found when trying to get lock; Try restarting transaction, message from server: "Lock wait timeout exceeded; try restarting transaction" (error code: 1205; sql state: 41000) Christian Gruber -- 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

17 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HBX-862) align propertyfile attribute usage to support override

by Max Rydahl Andersen (JIRA)

align propertyfile attribute usage to support override ------------------------------------------------------ Key: HBX-862 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-862 Project: Hibernate Tools Type: Improvement Components: ant Versions: 3.2beta9 Reporter: Max Rydahl Andersen Fix For: 3.2beta10 until now we initially load properties first then cfg.xml/other config....it should be the other way around to support overriding more cfg.xml/META-INF/persistence.xml -- 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

17 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HBX-861) JPA configuration should support propertyfile as a way to do overrides

by Max Rydahl Andersen (JIRA)

JPA configuration should support propertyfile as a way to do overrides ---------------------------------------------------------------------- Key: HBX-861 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-861 Project: Hibernate Tools Type: Bug Components: ant Versions: 3.2beta9 Reporter: Max Rydahl Andersen Fix For: 3.2beta10 brought up at http://forum.hibernate.org/viewtopic.php?p=2338703#2338703 -- 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

17 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2292) Regression between 3.2.0 and 3.2.1. Merge detached instance fails to persist ManyToMany relationship

by Mike Youngstrom (JIRA)

Regression between 3.2.0 and 3.2.1. Merge detached instance fails to persist ManyToMany relationship ----------------------------------------------------------------------------------------------------- Key: HHH-2292 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2292 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Reporter: Mike Youngstrom Priority: Critical I have a ManyToMany relationship. If I attempt to merge a detached instance of the owning side of that relationship the changes to the ManyToMany fail to be persisted. The merge propertly takes place and the persistence context is correctly updated but the SQL commands to update the database are not sent when the session is flushed. I'm using HA 3.2.0 and EM 3.2.0. If I replace the core 3.2.1 jar with 3.2.0 the operation works perfectly. If I attempt the operation on an attached instance the operation works perfectly. it only doesn't work with 3.2.1 with a detached instance. Here are the example entities and example code to duplicate the problem. --------------Animal.java--------------- @Entity @Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL) @SuppressWarnings("serial") public class Animal implements Serializable { @Id @GeneratedValue private Long id; private String name; @ManyToOne @Basic(fetch=FetchType.LAZY) private Classification classification; @ManyToMany @JoinTable(name="ANIMAL_COUNTRY", joinColumns=@JoinColumn(name="ANIMAL_ID"), inverseJoinColumns=@JoinColumn(name="COUNTRY_ID")) @Cache(usage = CacheConcurrencyStrategy.TRANSACTIONAL) @Basic(fetch=FetchType.LAZY) private List<Country> countries; @SuppressWarnings("unused") @Version private Long version; /** SNIP Getters and Setters **/ } ------------Country.java----------------- @Entity @Cache(usage = CacheConcurrencyStrategy.READ_ONLY) @SuppressWarnings("serial") public class Country implements Serializable { @Id @GeneratedValue @Column(updatable=false) private Long id; //NOPMD - wheelermm @Column(unique=true, nullable=false) public String name; @Basic(fetch=FetchType.LAZY) @ManyToMany(mappedBy="countries") @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL) public List<Animal> animals; } -----------Example code to duplicate problem---------------- //Start Transaction Animal animal = entityManager.find(Animal.class, 21l); animal = (Animal)SerializationUtils.clone(animal); // Detach the animal List<Country> countries = new ArrayList<Country>(); countries.add(countryService.findAllCountries().get(2)); animal.setCountries(countries); animal.setClassification(entityManager.find(Classification.class, 1l); animal.setName("Modified Animal"); entityManager.merge(animal); //Commit Transaction When the example code above runs both the animal.name and animal.classification are persisted but the change of country is not persisted. the object returned from entityManger.merge() contains the correct country but the db is never updated. if I comment out the clone() (making it not detached) everything works fine. If I downgrade to 3.2.0 everything works fine. Mike Forum post: http://forum.hibernate.org/viewtopic.php?t=968226 -- 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

17 years, 5 months

4
9
0 / 0

Maven repositories dont have the latest hibernate release

by kal stevens

Does anyone else use maven? I was trying to use it and realized that the maven repo was out of date. Could someone send an updated jar? I was not sure if this was the right place to make this request or maven. Thanks kal

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2378) replicate() of non-versioned entiy can result in wrong value for version in entity cache

by Max Rydahl Andersen (JIRA)

replicate() of non-versioned entiy can result in wrong value for version in entity cache ---------------------------------------------------------------------------------------- Key: HHH-2378 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2378 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.alpha1, 3.1.1, 3.1.2, 3.1, 3.1.3, 3.2.0.alpha2, 3.2.0 cr1, 3.2.0.cr2, 3.2.1, 3.2.0.cr3, 3.2.0.cr4, 3.2.0.ga, 3.2.0.cr5 Reporter: Max Rydahl Andersen Fix For: 3.2.2 if replication is called on a non-versioned entity and the entity already exists in the db it can result in the persister it self being stored as the version value for the entity (because AbstractEntityPersister.getCurrentVersion(..) returns any object if row exists and non-versioned). This result in a NPE in Lock.isPuttable because version is suddenly not null and thus a comparison is done wrongly. eg. Caused by: java.lang.NullPointerException at org.hibernate.cache.ReadWriteCache$Lock.isPuttable(ReadWriteCache.java:460) at org.hibernate.cache.ReadWriteCache.put(ReadWriteCache.java:155) at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:153) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842) at org.hibernate.loader.Loader.doQuery(Loader.java:717) -- 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

17 years, 5 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2377) Ability to specify clustered index

by Gareth Bowen (JIRA)

Ability to specify clustered index ---------------------------------- Key: HHH-2377 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2377 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: MSSQL Reporter: Gareth Bowen Currently the clustered index is generated on the identity attribute but this is often not optimal. There should be a way to specify which attribute(s) to make the clustered index on which defaults to the identity attribute if not supplied. -- 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

17 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HBX-859) cfg.xml generation should ignore "magic" properties

by Max Rydahl Andersen (JIRA)

cfg.xml generation should ignore "magic" properties --------------------------------------------------- Key: HBX-859 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-859 Project: Hibernate Tools Type: Bug Components: reverse-engineer Reporter: Max Rydahl Andersen Fix For: 3.2beta10 e.g. the following should not end up in hibernate.properties: <property name="hibernate.hbm2ddl.auto">false</property> <property name="hibernate.temp.use_jdbc_metadata_defaults">false</property> -- 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

17 years, 5 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2175) L2 Cache performance is very very bad when writing other kinds of objects in the same transaction

by Sami Dalouche (JIRA)

L2 Cache performance is very very bad when writing other kinds of objects in the same transaction ------------------------------------------------------------------------------------------------- Key: HHH-2175 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2175 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Environment: Hibernate Entity Manager 3.2.0 + Annotations + Core Reporter: Sami Dalouche Hibernate L2 Cache performance is very slow when writing objects in the same transaction. For instance. Let's say we have 2 completly unrelated classes A and B let's say A never changes, and we write tons of instances of B to the database. Both A and B are managed by the cache, but into differet cache regions (with different Ehcache configurations). So, let's consider a simple example like : loop 1: for(int i = 0 ; i < 10000 ; i++){ new A(); } and loop2: for(int i = 0 ; i < 10000 ; i++){ aDao.findAByKey("key"); } Since the L2 cache + Query cache is activatedon a + findAByKey, loop2's performance is comparable to loop's 1 one. It's pretty much the same, so everything is fine, so far. Let's call X the time taken by loop1 or loop2, that we consider equal. Now, let's consider loop3 and loop4: loop 3: for(int i = 0 ; i < 10000 ; i++){ new A(); bDao.save(new B()); } and loop4: for(int i = 0 ; i < 10000 ; i++){ aDao.findAByKey("key"); bDao.save(new B()); } So, now, let's consider that saving bDao.save(new B()) takes Y seconds for 10,000 iterations. You would expect loop3 and loop4 to have the same performance, roughly , X + Y, right ? Well, actually, loop3 takes X + Y. But loop4 takes around 20 * (X + Y) !!!!!!! (on my machine, so it can be slighly different). But you see the point : there is a HUGE difference of performance. I am sure there are design reasons for this, that's why I set this bug as an enhancement.. So, 2 things : * either it is possible to solve this issue, and it would be nice to correct it * either it is not possible to solve this issue, and it would be nice to add a section in the reference manual, explaining why hibernate behaves that way. Regards, Sami Dalouche -- 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

17 years, 5 months

3
4
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1889) LockMode.UPGRADE not applied in all cases for SQL Server / Sybase

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1889?page=all ] Steve Ebersole resolved HHH-1889: --------------------------------- Resolution: Fixed trunk / 3.2 > LockMode.UPGRADE not applied in all cases for SQL Server / Sybase > ----------------------------------------------------------------- > > Key: HHH-1889 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1889 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0.cr2, 3.2.0.cr3 > Environment: Windows XP, Hibernate 3.2.cr3 > Reporter: Matthias Germann > Assignee: Steve Ebersole > Fix For: 3.2.2 > Attachments: AbstractEntityJoinWalker.java.patch, SQLServerDialect.applyLocks.patch > > > Passing a LockMode parameter to the get(), load() or refresh() method of the Session class has no effect on MS SQL Server. > The statement > session.load(ProcessInstance.class, 33l, LockMode.UPGRADE) > produces this SQL Statement with the SQLServerDialect: > select > processins0_.ID_ as ID1_20_0_, > processins0_.VERSION_ as VERSION2_20_0_, > processins0_.START_ as START3_20_0_, > processins0_.END_ as END4_20_0_, > processins0_.ISSUSPENDED_ as ISSUSPEN5_20_0_, > processins0_.PROCESSDEFINITION_ as PROCESSD6_20_0_, > processins0_.ROOTTOKEN_ as ROOTTOKEN7_20_0_, > processins0_.SUPERPROCESSTOKEN_ as SUPERPRO8_20_0_ > from > JBPM_PROCESSINSTANCE processins0_ > where > processins0_.ID_=? > This Statement does not contain the requested locking hint. The FROM claus should look like this: > from JBPM_PROCESSINSTANCE processins0_ with (updlock, rowlock) > The OracleDialect produces a correct statement with a FOR UPDATE clause > select > processins0_.ID_ as ID1_20_0_, > processins0_.VERSION_ as VERSION2_20_0_, > processins0_.START_ as START3_20_0_, > processins0_.END_ as END4_20_0_, > processins0_.ISSUSPENDED_ as ISSUSPEN5_20_0_, > processins0_.PROCESSDEFINITION_ as PROCESSD6_20_0_, > processins0_.ROOTTOKEN_ as ROOTTOKEN7_20_0_, > processins0_.SUPERPROCESSTOKEN_ as SUPERPRO8_20_0_ > from > JBPM_PROCESSINSTANCE processins0_ > where > processins0_.ID_=? for update > The lock() method works correctly. > IMHO, the problem is that only the SimpleSelect class uses the appendLockHint() method of the Dialect class. The Select class does not seam to use the appendLockHint() method. -- 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

17 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2007