I am using Hibernate 2.1 and Sybase 12.5
Our system is a simple OLTP with applet client and minimal J2EE on the server.
Client requests will be initiating comamnds on the server. Each command will be initiated by a StatelessSessionBean and my JDBC Transactions starts here.

Our business rules are Plain Java classes. if all business rules are passed, we will persist the object(s).

The classes responsible for persistence are also a Plain Java class. But, they will get the Hibernate Session Factory created outside the scope of the transaction (FYI: FactoryLookup and DataSource lookup are done as part of the application deployment in the startup and cached - to avoid expensive JNDI lookup everytime).

Now, using the cached factory, we are creating the Hibernate Session and using the it for persistence. We are using mix'n'match approach - use Hibernate and plain JDBC, where ever it is fit.

All operations are under the CMT that was started in the Stateless Session Bean. Finally when the work is done, it CMT commits.

Are there any unpleseant surprises with the approach we are trying to follow??

Thanks
Vamsi

Are you using the same connection for JDBC and Hibernate use in a single business process?
If yes, you should beware session cache consistency related to what you've done behind the back of Hibernate.

Say there is a business use case, which involves 4 databse updates,
U1, U2, U3 and U4 in the same order.
If U1, U2 are using the Hibernate and U3 using Connection from JBoss DataSource Conn Pool, and U4 again using Hibernate,

U1
U2
session.evict(u1 and U2 objects) or session.clear()U3 (using Plain JDBC)
U4

Will the above approach work??

Well I don't know the JBoss datasource but in the same CMT, JBoss probably give you the same connection it gave to Hibernate.
And this is good, it avoids 2PC.
The evict stuffs are fine (flush() before not to lose what you've done)