Why does CMT commit on exit of ejb method when transaction attribute is "Required"?

I am consistently finding that my already-existing transaction is getting committed inside any method of an EJB marked @ejb.transaction type="Required". Can this be correct?

My expectation is, an EJB "requiring" a transaction means: if there's one already there, it will politely leave it uncommitted when done so that whoever invoked begin() can continue to use it for further operations before invoking commit() or rollback(). [Of course, if there was no transaction in the first place, then the EJB method would invoke both begin() and commit()/rollback().]

Is my expectation wrong, or should I be looking for a configuration bug?

It might be relevant to add that I'm using Hibernate 3 inside the EJB. I'm obtaining a UserTransaction before calling the EJB method. The EJB generated wrapper invokes ServerTransaction.commit() on exit, which Hibernate hooks into and uses the opportunity to close its Session. The error I'm getting is a Hibernate lazy loading exception, because the session is closed when I try to access getters on a Hibernate-persisted object. So technically, I'm not 100% sure whether the ServerTransaction.commit I observed necessarily committed the UserTransaction I started (maybe ServerTransaction.commit doesn't always actually follow through with a "real" commit?), but if it did not -- then on what basis is Hibernate closing the Session?