Is storing server resources in application instance safe?

General
1

Hi,

If I’m not wrong, the Application instance is serialized into the session and retrieved from there when needed. In the AddressBook + JPA article it passes a reference of an EJB instance in the constructor to the Application class and saves the refercens of the EJB as a class property. Is this safe? Can I save instances of DataSource, EntityManager or similar server side resources in the Application instance? I think this may cause a problem in Serialization. If this is not safe, then what is the best practice in accessing these objects? Is there a method on the AbstractApplicationServlet which I can override to pass these resources to the Application after deserialization? (So I can set these properties transient in the Application class)

Thanks

2

I think, storing references to EJB beans should be save as they must be serializable by the spec and survive serialization. As for the EntityManager and DataSource - I think this is anyway not a good idea to hold them for the long time. It is better to lookup the DataSource, for instance, each time you need it ans then release when your unit of work is done. DataSources are usually backed by the connection pools, so acquiring a new datasource from the pool will not be a expensive operation. The same is for EJB’s. with exception if you use stateful bean, but it should survice in a session object.

3

Saving references to EJB’s may also be a problem since the bean itself usually contains a reference to a non serializable datasource or something. And EJB’s are managed by the app server, they carry transaction information etc. When we serialize and deserialize the bean, these magical features will be disappeared.

I believe non of these will be a problem in a single server environment, however if we move our application to a clustered environment where the session objects are replicated, this may cause a problem. (For instance in google appengine)

Erdinc

4

Hi,

We’re not using EJB’s - just a ServiceLayer + DAOs + Hibernate - in our project, but I still had concerns about serialization. Our approach has been to use Spring to inject service layer objects into our app, and to make them transient.

For example, we have a Vaadin container ClientContainer, which has reference to a ClientService (which in turn has a reference to a ClientDAO). The ClientService is a Singleton. .

Vaadin Window → VaadinTable → ClientContainer → ClientService → ClientDao (-> DataSource)

The ClientContainer has a reference to ClientService that is
a) populated by Spring
b) transient, i.e. not stored when the Session is serialized
c) Spring “re-populates” the clientContainer attribute when the object is read from the session.

This is all done using the magic of AOP - for development, we are using load-time weaving, and then compile-time-weaving as part of the build script. We are far from experts on this, but it all seems to be working just fine - and logically, I see no reason why this couldn’t work in a clustered environment.

Snippet :


@Configurable(preConstruction = true, dependencyCheck = true)
@Component
@Scope(value = "prototype")
@SuppressWarnings("serial")
public class ClientContainer extends SortablePagingContainer {
  protected boolean numberOfRowsNeedsRefresh = true;
  @Autowired
  protected transient ClientService clientService;
[...]

Cheers,

Charles