This is the fourth article in a series of articles about common patterns and pitfalls when using Wicket (http://wicket.apache.org). Most of these patterns apply only when using Wicket in conjunction with Spring and Hibernate and these might be very specific, but others are more general. The
last article was about the OSIV-LDM-Pattern and its pitfalls. This time it's about HTTP session pitfalls.
Wicket Session Pitfalls
Environment: Wicket, Spring
Example Environment: Wicket, Spring, Hibernate, OpenSessionInView
When Wicket processes a request, the component hierarchy including the models is constructed, then events are processed, the response is rendered, and finally the components and models are put into the
PageMap. This is Wicket's way of storing state. The
PageMap in turn is put into the Wicket session, which is put into a
SessionStore, which is put into the
HttpSession (by default). And as the
HttpSession is a critical resource, one has to take care of the size of the components. Especially, the size of the models, that are attached to the components, can be of critical size - imagine huge amounts of table data or large object graphs. For this reason, Wicket provides models, which get detached at the end of the request, so that their model objects will not be put into the session (this generally means nulling out transient fields). But there are still some cases, where model objects are accidently put into the session. This article sheds some light on these cases.
The ExampleAs an example to demonstrate these cases, let's take an entity
Person ...
@Entity
public class Person {
@Id @GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private String lastName;
private String firstName;
...
}
... and a very simple page that displays the details of a person:
public class PersonPage extends WebPage {
public PersonPage(final Person person) {
super(new Model(person));
add(new Label("firstName",
new PropertyModel(person, "firstName")));
add(new Label("lastName",
new PropertyModel(person, "lastName")));
add(new Label("username",
new PropertyModel(person, "username")));
Link link = new Link("editLink") {
public void onClick() {
setResponsePage(
new PersonEditPage(person));
}
};
add(link);
}
}
The person entity is provided as an argument to the constructor. We call
super() with a
new Model(person) to associate the person model with the page, so we can get a handle to the person later on. Then we add some labels to display the details of a person. We provide
PropertyModels to the labels, which are used to access a property of the person using a property expression. Finally, we add a
Link, which directs the user to the
PersonEditPage, where the user details can be edited. We do so by setting the response page to a
new PersonEditPage(person). We pass the person instance, that was provided to the constructor of
PersonPage, to the edit page.
So, this is a really, really simple page. And in fact, it has some flaws, so that the person entity is put into the session. This is something we wouldn't want, because the person may be connected to a larger object graph (e.g. person references some orders, which reference some line items, which references items, ...), which would all be put into the session as well.
The person entity in this example is put into the session for different reasons. The following sections describe these reasons and give some rules to prevent model objects from getting put into the session.
Rule #1: Use detachable models for entitiesThe first one is a very basic one. In the example above, the person is passed as an argument to the constructor and then it's put into a newly created
Model instance. Now,
Model is the basic implementation of an
IModel (the base model interface in Wicket) and it does no more than keeping a reference to the entity, which is returned by
getObject() - no detaching at all. In fact, the constructor of the
Model class gives a hint that the model object is put into to the session: it just accepts model objects as an argument that implement
Serializable.
Model is not the only implementation of
IModel that does not detach entities. For example,
PropertyModels and
CompoundPropertyModels don't detach entites either. These models do some other kind of detaching, though, which is shown in the next section. But first, let's see, what we can do about the problem here. We are looking for an
IModel implementation that implements
detach() (inherited from
IDetachable) in a suitable way, i.e. detaching the entity from the model after the request. And in this case, we could use a
LoadableDetachableModel.
LoadableDetachableModel requires you to implement the abstract method
load(), which is meant to return the entity (e.g. fetch it from the database). When
getObject() of
LoadableDetachableModel is called, it calls
load() to fetch the entity and assigns it to a transient field. At the end of a request,
detach() is called, which nulls out this transient field, so the entity is not put into the session.
Rule #2: Rely on models, not on entitiesThe second reason, for which the person entity gets into the session in the example above, is the way the
PropertyModels for the
Labels are used. When
new PropertyModel(person, "firstName") is called, the
PropertyModel assigns the person instance to an internal, non-transient, never nulled-out instance variable. In this sense,
PropertyModel is no better than an ordinary
Model.
But we can still leverage the benefits of a
PropertyModel as it implements
IChainingModel in a proper way. That means, we can pass another person model to it as an argument instead of the entity itself, and it will chain through the calls to
getObject(),
detach() and so on. So, if we pass a
LoadableDetachableModel for the person to the
PropertyModel, we are fine:
new PropertyModel(loadableDetachablePersonModel, "firstName"). So, whenever it is possible, we should build models that rely on other models instead of the entities directly.
Rule #3: Do not assign entities to instance variablesThe example above does not violate this rule, so here is a variation of the
PersonPage that does:
public class PersonPage extends WebPage {
private Person person;
public PersonPage(final Person person) {
this.person = person;
...
}
}
In this case, the person instance gets put into the session, simply because the page is put into the session, as all components are. It's easy to follow this rule. Just follow rule #1 and rule #2.
Rule #4: Do not circumvent @SpringBean proxiesThis rule is kind of the same as rule #3 but related to
@SpringBean annotated fields (when using Wicket in Spring container). When a field of a component is injected with the use of
@SpringBean, what really is assigned to the field is a proxy of that spring bean.
public class PersonPage extends WebPage {
@SpringBean
private PersonDao personDao;
public PersonPage(final Person person) {
...
}
}
As this is a lightweight proxy of the
PersonDao, rule #3 is not violated. In fact, the
@SpringBean-proxy-mechanism is a good example of following rule #3. Anyway, while it's okay to keep a reference to this proxy, it's not okay, to pull other spring beans out of the proxy and assign them to instance variables. Example:
public class PersonPage extends WebPage {
@SpringBean
private PersonDao personDao;
public PersonPage(final Person person) {
super(new PersonModel(
personDao.getSessionFactory(),
person.getId());
...
}
}
public class PersonModel
extends LoadableDetachableModel {
private SessionFactory sessionFactory;
private Long personId;
public PersonModel(SessionFactory sessionFactory,
personId) {
this.sessionFactory = sessionFactory;
this.personId = personId;
}
public Object load() {
return sessionFactory.get(personId);
}
}
When
personDao.getSessionFactory() is called, the real sessionFactory is returned, of coures. No proxy. Then it's passed to the
PersonModel which holds a reference to it, and the
sessionFactory will be put into the session along with this model. We can prevent this by injecting the session factory by using
@SpringBean as well.
Rule #5: Implement anonymous inner classes carefullyThe
PersonPage in the example uses a Wicket
Link to redirect the user to the person edit page. The
Link is implemented as an anonymous inner class in order to implement its abstract method
onClick(). Many Wicket components are implemented this way, and as a result, anonymous inner classes are very common in Wicket.
public PersonPage(final Person person) {
super(new PersonModel(person));
...
Link link = new Link("editLink") {
public void onClick() {
setResponsePage(new PersonEditPage(person));
}
};
add(link);
}
The
onClick() method is implemented in the most straightforward way. The person instance, which was passed as an argument to the constructor of
PersonPage, is passed to the constructor of
PersonEditPage, which is set as the response page. It's not easy to see immediately, how the person is getting into the session now, but in fact it's put there. And it can happen as easily in many other cases using anonymous inner classes.
This is because in Java, when an inner class, declared in a method (or constructor), accesses a variable of its declaring method, such as an argument or a local variable, this variable effectively becomes a member of this inner class. This is because these variables have to be declared
final to be able to access them from inner classes. In the example above, the
person parameter becomes an instance variable of the anonymous
Link class, and as rule #3 has shown, instance variables are put into the session along with the components they belong to.
Rule #6: Always attach models to componentsThis rule also relates to rule #3. This time it's about models as instance variables. Let's add an instance variable of type
IModel to the person edit page.
public class PersonPage extends WebPage {
private IModel accountModel;
public PersonPage(final Person person) {
super(new PersonModel(person);
this.accountModel = new AccountModel(
person.getAccount());
}
}
Let
PersonModel and
AccountModel be properly implemented
LoadableDetachableModels. So what's wrong with assigning a
LoadableDetachableModel to an instance variable? After all, it's a lightweight model and the
PersonModel is assigned to an instance variable somewhere in the page hierarchy, too.
Actually, the
PersonModel is assigned to a component, which takes care of detaching the model. A
LoadableDetachableModel has to be detached by some component that knows about this model. And this is not the case with the
accountModel. No component ever calls its
detach() method, as it's not attached to a component as a model. We could implement some detachment logic for this model in the person page, though.
ConclusionThe conclusion of this article is simple: If you use objects of some serious weight in components, don't use them directly. Instead use an
IModel implementation, that implements a proper detachment logic, or use some kind of other leightweight representation of that object like an ID or a
@SpringBean proxy.
Posts
