Hi, i'm new to hibernate.
My conceptual schema is [ Doctor (1) <----> (*) Person ].
Suppose you have on database two rows of Person (ids : 1L, 2L) and one row of Doctor (id=1L); moreover doctor(1L) ---> person (1L) and doctor(1L) ---> person(2L)

My question concern the following code snippet :

Session ms = sf.opensession();
ms.beginTransaction();

Person p1 = (Person) ms.load(Person.class, 1L);
ms.delete(p1);

Doctor d1 = (Doctor) ms.load(Doctor.class, 1L);
Set<Person> people= d1.getPeople();
Assert.assertEquals(1, people.size());

The last assert fail.
Hibernate shouldn't understand that p1 is no more associated with d1?

If is not possible in this way, how can i reach my purpose?

In the code example you show the simplest way is to issue a flush() after deleting the person:

Thanks for your reply; execute ms.flush() solve this case, but the problem is more complex.
Imagine that you must manage a long unit of work, the classic question of conversation.
If you are forced to call flush() to have the results of the queries updated, conceptually this imply to have jdbc connection open while the conversation end.
Maybe i don't know what really happens when i call session.flush(), i suppose that the updates collected inside session are written into a jdbc connection. It's correct?

Most operations on the session are only queued internally in the session. Synchronization with the database is done at flush time. This can happen at different times but the only way to be really sure that the internal state has been synchronized with the database is to call flush() or commit(). There is some information about this in the documentation: http://docs.jboss.org/hibernate/stable/ ... e-flushing

did you try this?
--from hibernate doc [1]:
In our case, a Child cannot exist without its parent. So if we remove a Child from the collection, we do want it to be deleted. To do this, we must use cascade="all-delete-orphan".

<set name="children" inverse="true" cascade="all-delete-orphan">
<key column="parent_id"/>
<one-to-many class="Child"/>
</set>

[1] http://docs.jboss.org/hibernate/stable/ ... child.html

The problem is how much is expansive synchronization with database; it's reasonable implement 'session per conversation' calling flush on every user request ?
As specified in many use cases, when you share persistence context to implement 'session per conversation', the only call to session.flush() is at the last user request; i think it's for performance reason.
The application that i'm developing is a web application in which user navigate through database and create, delete, update records (also adding/removing association between objects); a single user conversation may take several minutes; in this time, user can modify several objects without commit, and want to see his temporary changes.
So in the previous example, if user delete p1 Person object , when open Doctor d1, he don't want see p1 inside associated; the only way i can reach this, is flushing the session after the first delete user request; but it's reasonable exec flush() every time that user change something?? What happens if i flush the session 30 times during a user conversation?

I have no experience with the session-per-conversation pattern, but disregarding this, it should not really matter if you call flush() or not. In the end all changes needs to be SQLed to the database and if that happens now and then or only at the end of the conversation should only have marginal effect on the performance.

The problem is I assume that each request still has it's own transaction and if you flush in a middle step the changes will be committed to the database and there is no way of rolling back this when the conversation ends. So, if you want to use the session-per-conversation pattern you should not flush until the end.

But then you also need to be aware of that queries are always executed against the database and since what is in the database may not match what is stored in the session the result may be unexpected. In the above code example you could do:



But I guess in the more complex case it will be too complex to get this correct and also too demanding when it comes to future changes and code maintenance. I have no good solution for this problem. Maybe you can keep your own "cache" of items that have been deleted and then display some kind of marker icon in the web interface.

Finally, to answer the question in the original post: Hibernate shouldn't understand that p1 is no more associated with d1?

p1 is still associated with d1. It has only been marked for deletion, and as long as the deletion hasn't happened (eg. the session has been flushed) it is associated with d1.