[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, 4 months
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, 4 months
[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, 4 months
[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, 4 months
[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, 4 months