-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 
Author Message
 Post subject: While select, some unexpected updated queries are executed
PostPosted: Thu May 04, 2006 12:24 am 
Newbie

Joined: Wed Mar 29, 2006 11:54 pm
Posts: 4
Hi,

my code is this

private List loadAll() {
List featureList = null;
DAOManager.createSession();
DAOManager.beginTransaction();
Session session = DAOManager.getSession();
Query query = session.createQuery("from Feature order by UserGroupID asc");
featureList = query.list();
DAOManager.commitTransaction();
return featureList;
}


the above is working fine. after that i did not do any other retrive are updates. but at the time of executiom when the control comes over DAOManager.commitTransaction(); line, some update query for same Feature entity is running.

why that update query are excured..?

_________________
Regards
A.Peter
SCJP,SCWCD


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 04, 2006 2:01 am 
Expert
Expert

Joined: Thu Dec 23, 2004 9:08 pm
Posts: 2008
I think that the question you are asking is:

I load some objects from the database in a transaction. When I commit that transaction, some objects are saved back to the database. Why? How do I stop this?

Am I right? I'll answer that question anyway: if that's not what you are asking, can you try rephrasing the question and I'll try again.

The most likely explanation for this is that one (or more) of your mutators (set methods) does something "odd". For example:
Code:
public class Feature ...
{
   ...
  public String getName()
  {
    return this.name;
  }

  public void setName(String name)
  {
    this.oldName = this.name;
    this.name = name;
  }
  ...
}
Assuming that the oldName property is also in the Feature table, this code would cause objects of the Feature class to always be saved. When the object is loaded, it modifies itself so that it is no longer the same as the object in the database, and hibernate detects this and saves it when the session is flushed.

The solution is to eliminate code like this. A standard way to do this is to have different accessor/mutator (get/set) pairs for use by API users. For example:
Code:
public class Feature ...
{
   ...
  public String getName()
  {
    return getInternalName();
  }

  public void setName(String name)
  {
    setOldName(getInternalName());
    setInternalName(name);
  }

  public String getInternalName()
  {
    return this.name;
  }

  public void setInternalName(String name)
  {
    this.name = name;
  }
  ...
}
Then you call the property "internalName" in your hibernate mapping file, but you use the getName() and setName() methods in java code. This avoids the problem.

Hope I've answered the right question. Post again, if I haven't.

_________________
Code tags are your friend. Know them and use them.


Top
 Profile  
 
 Post subject: Hi tenwit,
PostPosted: Thu May 04, 2006 7:55 am 
Newbie

Joined: Wed Mar 29, 2006 11:54 pm
Posts: 4
What you said is exactly my solved my problem.


Thanks a lot.

_________________
Regards
A.Peter
SCJP,SCWCD


Top
 Profile  
 
 Post subject:
PostPosted: Thu May 04, 2006 6:54 pm 
Expert
Expert

Joined: Thu Dec 23, 2004 9:08 pm
Posts: 2008
You're welcome. Feel free to award a credit.

_________________
Code tags are your friend. Know them and use them.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 19, 2006 10:40 pm 
Newbie

Joined: Fri Apr 22, 2005 4:33 am
Posts: 9
Hi tenwit,

One of my colleagues encountered this problem few days ago and ask for my help with it. Your response did help me. Thanks.

BTW, do you know whethere it is a "FEATURE" or "DEFECT" since we DID NOT ask Hibernate to "UPDATE/PERSIST" this POJO? What we do was only executing the find method and it seems that Hibernate try to guess what my intention was of this and executed the "UPDATE" statements for me even it was really NOT what I want.

------------------
paxsonyang


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 19, 2006 11:01 pm 
Expert
Expert

Joined: Thu Dec 23, 2004 9:08 pm
Posts: 2008
Neither, it's just your colleague's imperfect understanding of what's supposed to happen. If you really want to be allowed to modify a persistent object and then not have it saved to the database when you flush/commit, you must evict it before flush/commit.

When you write your data access objects, you must be aware that hibernate will save any changes you make, even unintentional changes. Hibernate does not require you to call session.save()/session.update() to save objects if they are persitent. It doesn't guess what you are trying to do: it knows that you made a change to a persitent object, and therefore that you wanted to save it. If you didn't actually want to save it, then you shouldn't have modified it.

_________________
Code tags are your friend. Know them and use them.


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 19, 2006 11:39 pm 
Newbie

Joined: Fri Apr 22, 2005 4:33 am
Posts: 9
Hi tenwit,

Thank you for your reply. Yes, you are right. We should know that Hibernate always sync changes we made on POJO when the session is "open" even you just find it from database.

We shall keep it in mind that any changes on POJO shall trigger required "UPDATE" in database when it is "attached" to the session.

We use Spring+Hibernate in our application and never encountered this problem before since in most cases, every POJO have been "deattached" from the session when we update its attributes.

Thank you again for your quick and professional response.

------------------
paxsonyang


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 7 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.