Reading the book hibernate in action I was interested in noting a certain bias towards using the generated hibernate objects in the business layer - rather than separating concerns and having the data layer its own subsystem.

To be honest that is what I have always done with reasonable success but now that I am embarking on an extremely large object I would probably question to whether this is a great idea. Changes in the data model will require retesting a lot of functionality.

Specifically this is 1000+ concurrent fact client (Swing) OLTP users (real transactions not shopping carts...).

Does it make sense to have the client apps create Hibernate sessions directly?

I suspect so but would like to vet the idea...

I approach architecture as "what is a good theoretical approach" Then I back off from the "ideal" until there is something that works in the real world. Come up with a few test cases and a harness and give it a shot with under stress and junit / jmeter. It is an agile world after all ;)

In all practicallity, I would definately suggest keeping any hibernate specific calls or imports out of the biz layer and biz classes. Put them in utility classes at least; if not in their own persistence services (thinking SOA here) You can always refactor if needed to smoosh the layers together if truely needed. What costs your organization more? faster/more CPUs or maintainance / enhancement of a highly coupled system?