FAQ

Database connection not passed back to the connection pool after the HTTP request

Depending on your environment and used JPA-implementation you might experience the problem that there are database connections which have not been passed back to the connection pool.

This can happen if you use entities with e.g. OneToMany mappings and lazy init AND accessing the OneToMany collection from your JSF view the first time.

The EntityManager has to re-establish a connection to your database, but now that this happens outside of your conversation scoped bean, no one ends the transaction and so no one puts the connection back to the pool.

The problem is that with a growing number of users and a growing number of conversations (especially not ended conversations - waiting for their timeout) your pool might exhaust.

As said before, this might not be the case with all JPA-implementations. But we had at least one environment where this happened, so here the work-around.

To activate the workaround simply put the following code in your spring config and adjust the names as required.

<bean id="managedDataSource" class="org.apache.myfaces.orchestra.connectionManager.ConnectionManagerDataSource">
	<property name="dataSource" ref="dataSource"/>
</bean>
					
The basic principle is to put a virtual DataSource between the JPA-implementation and the read DataSource (which should be a connection pool for performance reasons).

You have to configure
  • the property dataSource to point to the original datasource and
  • the JPA configuration to use our managedDataSource (adjust the name if required)

PropertyPlaceholderConfigurer STOPS working after the introduction of orchestra into my configuration

Use the <aop:scoped-proxy> configuratino with in the persistentContextConversationInterceptor definition. You'll end up with something like:

<bean id="persistentContextConversationInterceptor" class="org.apache.myfaces.orchestra.conversation.spring.PersistenceContextConversationInterceptor">
    <aop:scoped-proxy/>
    <property name="persistenceContextFactory" ref="persistentContextFactory"/>
</bean>
					

The reason is, that, during startup of the spring system when the custom scope will be initialized, the system might already require a datasource, but at this time the PropertyPlaceholderConfigurer didn't run already.

Using the <aop:scoped-proxy> configuration allows the initialization process to end cleanly.

The ViewController events are called twice

If your VieController event methods are called twice you probably configured the ViewControllerPhaseListener in your faces-config.xml which is not required.

Orchestra already does this for you.

Is it possible to pass an entity from one conversation scoped bean to another?


No!

The reason is, that the entity is associated with a persistent context which is different between the various conversation scoped beans.

You are safe if you just pass the surrogating key around.

This is not an Orchestra limitation, but more a technical limitation of how the ORM work today.