Please enlighten us regarding the bolded section below. How does the synchronization of data in the persistence context from an outside transaction (say from query analyzer, etc.) occur? And is that part of the JPA 1.0 spec or specific to Hibernate as the persistence provider?
Putting aside that Spring WebFlow requires you to use a stateful pageflow, and comparing it with Seam on other bases, both solve the most fundamental problem in enterprise applications, management of the persistence context. The persistence context (e.g., the JPA EntityManager or Hibernate Session) is a stateful component. It was intended to remain open for the lifetime of the use case in which you are modifying the entities that it retrieves.
Case in point. You select a record for editing. You modify that record. Then you save it. The persistence context should remain open for that entire use case. Then, the ORM tool (e.g., JPA or Hibernate) can automatically detect changes and push them to the database. Better yet, it can detect when the database has been altered in the interim and prevent those changes from overwriting someone else's changes. There are a whole host of other features, such as persistence by reachability, that simply make the task of database saves and updates completely automated.
The mechanism I refer to in the bolded section is actually a feature of JPA and Hibernate (Seam just relies on it). You simply mark one of the mapped properties in your entity as the version property (there can be only one)
Prior to saving or updating the object, the persistence manager verifies that the value of the @Version property on the entity instance in persistence context is equivalent to the value of the mapped column for this record in the database. It is a simple SQL verification. This all happens within a database transaction, so the check is atomic.