What is the transaction scope in a typical EJB3/JPA/JSF?

Question

Suppose you have a web app with EJB3/JPA and JSF stack. AFAIK you can design your screens using different managed beans, eg, let's suppose a HeaderBean and a ListingBean. Since there's no OSIF pattern in EJB3 AFAIK, how many different transactions are executed in the following pseudo code:

@ManagedBean
class HeaderBean {
  @PreConstruct
  load(){
    // enters transaction boundary, probably will create a new tx
    headerInfo = ejb.loadFromDb();
  }
}

@ManagedBean
class ListingBean{
  @PreConstruct()
  list(){
    // enters transaction boundary, probably will NOT join the headerBean tx
    List<Data> listing = eao.loadFromDb(0, 20);
  }
}

AFAIK when you leave the EJB layer all transactions are committed; so if I call two different SLSBs from the presentation layer, it would run in two different transactions (and possibly break my ACID expectations right?).

---

Clarification: I am aware of EJB3 transactional behaviour such as required, never, requires_new and so on. My question is more about how View-First (such as JSF) promotes this kind of design where the screen data can potentially span multiple transactions, and thus potentially inaccurate.

I prefer longer transactions but correct data than short transactions but incorrect data. I was wondering if new frameworks such as jBoss Seam somehow promote this or offer an alternate design (eg: Open-Session-In-View pattern).

Answer 1

There are options to control the transactional behaviour of EJBs. Usually they have a "Requires a transaction" setting, so that if a bean is called with a transaction in place then the work of the bean is included in the already established transaction, otherwise a transaction will be started and completed when the bean returns.

In your code, on entry to the EJB there's no transaction in place, so as you say on return from the EJB any transaction has been resolved.

Although this seems potentially problematic in that you potentially get inconsistent views of the data, I think this behaviour is desirable. We want the time spent in a transaction to be short - otherwise database locks are held for extended periods and hence concurrency suffers.

The EJB layer should be seen as providing atomic services and designed and used accordingly. I don't know whether I'm reading your code correctly, but having separate access methods for the Header and the Body may not be the best design. If you need consistency between header and body fetching all the data in one call may be preferable, and actually more efficiently done in a single DB interaction.

--added--- You have clarified in your question that you are indeed concerned about consistency between different portions of a screen that if coded using simple JSF techniques would use separate transactions.

In my opinion the default JSF approach is approapriate when such inconsistencies are either highly unlikely or unavoidable. Examples: 1). Unlikely: query historic data, total of yesterday's transactions and list of yesterday's transactions. In a system where history cannot change such separate queries will be consistent. 2). Unavoidable: summary comes from one system, details from a different system, there is no transactional coordination between the two systems, we cannot ensure consistency. We just have to present to the user indications that the two views may be slightly out of step.

Where you really want consistency use a different approach, get all the data in a single request and save it (say in session or request) then use it in the two views - views should not be fetching their own data if you care about such things.

I think you will find that attempts to use transactions to keep things consistent will add considerable complexity as well as impacting throughput. The problem with coordinating transactions across views is that there's no simple "owner", if you recompose the page you will need to change the logic