Hi all,
I know how to evict a object from current session and what evict means. But I have one query, regarding this. I hope somebody tried this before and guide me.
Consider a case, where I have Department Entity. Now it contains list of Employees. Employee has list of Project as Many to Many relationship.

i.e. Department 1______ M Employee and Employee M ______ M Project.
a very ordinary and regularly used example. Now, the questions.

1) if I evict, say one Employee(whatever may be the condition to choose such an employee, like employee is now retired) from the Emp List contained by Department, then collection of Project contained by the Employee, will also, get evicted or not????

2) After eviction, If I query only that specific employee, may be using its Id i.e. primary Key value, then will, this object be, still in the Department List?? Or for that, I have to remove previous object, now detached from session, from List and then add this one to the list???

Please, I will appreciate, any help or any extra information. I think, this is interesting.

Hi, as far as I have understood evict, it will simple removes the object from the session-cache.

So all relations will be still correct and as before. If you try to access this object (in your case your employee) directly or via relation, hibernate will try to load it again from the database.

If you keep the object and also load it from the database, you will have two representations of the same object in memory. (cause foo1 != foo2 but foo1.id.equlas(foo2.id)) If you try to save the detached object then you will ran in trouble, cause hibernate rejects it, cause another object with the same db-id is still present.

If the list of projects aren't referred by other objects,
they be should also be evicted. Cause if it makes no sense to keep objects in the cache which you can't reach any more.

Evict is primarily necessary for long conversation or "Open-Session in View" to avoid above problems.

Greetings Michael

it's possible to define the eviction policies to be used on collections, as you can define a "cascade delete" you can also specify "cascade evict", so what really happens depends on your configuration.
http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#objectstate-transitive

First of all,
Thanks to Michael and s.grinovero, for replying.

Ok! I got it now! But now, I am using Seam Framework, in which you can have something like session-per-conversation pattern, but managed by Seam Framework itself. So less headache for developer.
I want to show, tree display, where, it has One to many relationship between Parent and child, ( again, very obvious). Now, when User expands a Parent node, due to session-per-conversation pattern, getting lazily loaded children is something like calling properties like, Parent.getChildren(), for associations, mentioned in Parent.
So far, so good. Now, when user collapse this Parent node, I want to remove all children i.e. evict() and want to change the state of Parent so that, when we again access Parent.getChildren(), Hibernate should query for fresh data for available Children.
Now here, if Parent is at top level in tree, Evicting all children and querying for that particular Parent will be sufficient to, lazily initialize (with proxy object and no actual data) children collection.

But, now think of situation, where Parent is at say 2nd level in Tree. Thus, Parent itself is into a collection, say at position at 0. Now, I want to remove its children, but, I want Parent to be inside collection. So, that, when
Parent = SuperParent( i.e. Parent's parent).getChildren()(getting collection of all nodes at Parent level).get(0);
Parent.getChildren(), should query for fresh data for children.
I just don't able to figure out , how to achieve this.

I request Michael and s.grinovero to help me out with their experience. Also, input from other members of this Hibernate community is quite welcome.

Thanks
Simit

That is , I want a way to, evict only collection of children (and all children contained by collection, of course) from Parent and when next time we say Parent.getChildren(), Hibernate should access / load fresh data for children.

Is there a way???

Hi, I don't understand, why you care about the session-cache, if you use the "session-per-request"-pattern.

If you use this pattern, the session is closed immediately after your request. So also the complete cache is evicted/dropped. You can check this with session.contains. I'm quite sure your evict-calls aren't necessary, cause they aren't in the cache.

I don't use Seam, so I don't know, if you have to use begintransaction and commit or rollback explicitly to mark the begin and end of your request. (May be also done by CMP implicit)

If you don't want to change the lazy loading behaviour, you can use special queries (or Initialize) to load exactly what you need. This normally the recommend way.
Open-Session-In-View is only the second best solution. So If you develop a completely new app, try to load everything what you need.

If you have a read only setup and want to be sure that you get the latest data from the db, you can use session.refresh to ensure your parent object is updated. Then you can also use Hibernate.Initialize on your Collection to ensure that they are loaded. If you want to be absolutely sure that you have the latest version, you can iterate through the collection and use refresh on these objects. (Use "batch-size" to prevent performance draw backs.)

It is quite hard to ensure in a web-app, that everything is up to date. Even if you can ensure that at load time, you don't know when the user is watching that information.
So I hope you don't rely on that fact. I would prefer to check if the data is still up to date, if the user does the next step. (E.g. if he tries to submit his order, you should check,
if everything in the basket is up to date.)

Cause the session should be new, they can't be in the cache. What you should avoid is to keep any java-refs of the children, cause these objects (detached) aren't updated unless you do this explicit.

Also keep in mind that you can have two instances of the same db-object, cause foo1 != foo2, but foo1.equals(foo2) is not the same. So even you may have refreshed foo2, foo1 may be still out of date.

Greetings Michael