OK, I know this is not primarily a Hibernate question, but the smartest database/enterprise people I know are on this forum, so I'm going to try picking your brains here.

We have a pretty typical stateless-session-bean service layer (facade, if you will) on our Hibernate domain model.

We have a number of integration tests that make EJB invocations of this service layer.

We seem to be in a situation where in some deployment configurations (namely those with the database on a different machine than the EJB app server), database races are causing our tests to fail.

In other words, let's say we have a BidServiceBean, with two methods, createBid and updateBid. And we have a test case that does:



What we get is an exception from the updateBid method, saying that the id of the bid is not found.

This only happens sometimes -- it is definitely timing-dependent -- and it happens a lot less when the database is colocated with the app server.

It looks to me as though the app server is saving the bid in a transaction, getting the bid's id, committing the transaction, and then returning the bid with the id. But the commit takes a while (this is with Postgres) and the test case is running much faster. So the updateBid call comes in before the commit has hit the database and the app server's transaction for the updateBid request does not see the new Bid!

Is this a well-known, boring, yawner problem with some solution that I am just ignorant of? Basically, is there any good way to tune the system such that database commits done by (stateless) session beans are guaranteed to be seen by subsequent (stateless) session bean invocations? If not, are there design principles for avoiding these kinds of races?

Thanks very much,
Rob