Is the following normal behavior for Hibernate?

Context: I have a UI that uses long-running hibernate sessions to manipulate Java objects, then saves them back to the database in one transaction when I am done.

[list=]
I open a hibernate session.
I load an entity A from the database into memory.
I create an empty element B under A, which goes into a many-to-one list under A. Important: B has certain fields with not-null="true".
Before filling in all the not-null B fields, I perform another operation which causes a query to be executed.
The execution of the query causes a flush to occur, which throws an exception "PropertyValueException: not-null property references a null or transient value", because I had not yet filled in all of the not-null fields in B
[/list]

I saw the FlushMode.COMMIT option, but I also read in Gavin's book that it is not recommended to change this setting.

Is my only option to create B as a standalone entity, and fully validate it before attaching it to A? That is going to be very awkward, because this UI is supposed to let the users play around with the data, adding and removing and changing perhaps many things before committing.

I guess another option would be to forego the not-null constraint, but that would be a shame not to let the database help me enforce data integrity rules.

I feel I must be missing something. Any insight is much appreciated.[/list]

I was wondering what evict() was for! It seems that it's a good idea to evict the entity from the session while it is being edited, then call saveOrUpdate() on it when the user is done.

I have done this and it seems to be working so far.

Is this the standard practice? Any gotchas with this approach?