2

I would like to have a static read only collection in a stateless session bean. Ideally it will only be initialized once and available to bean instances as long as the application is running.

Let's assume that this application is deployed in a clustered environment with multiple servers/JVMs.

As I understand it, in the first case, the static variable barList gets initialized at the same time when the bean is created by the container and lives as long as the bean (or maybe even longer?) and there's no danger of it being garbage collected while the bean instance is alive.

In the second case, barList gets initialized when the Foo class gets loaded which is when the bean's getBarList() method gets executed. What happens when it's returned though? Will it be destroyed after the bean method is done executing?

Case 1: 

@Stateless
public class MrBean implements BeanInterface{

private static final List<Bar> barList;

static{

barList = new ArrayList<Bar>();

//create some bars, add them to the list

}

public List<Bar> getBarList(){

    return barList;
}
}

Case 2:

@Stateless
public class MrBean implements BeanInterface{

public List<Bar> getBarList (){

return Foo.barList;

}

}

public class Foo {

public static final List<Bar> barList;

static{ 

barList = new ArrayList<Bar>();

// create bars, add them to barList 

}

}
bez
  • 177
  • 1
  • 14
  • By definition you can't be "stateless" and remember state in a static field - indeed, it breaks the standard. See [this answer](https://stackoverflow.com/questions/9141673/static-variables-restriction-in-session-beans) for more details. – stdunbar Jul 20 '17 at 18:12
  • @stdunbar OK, I added "final" declaration. – bez Jul 20 '17 at 18:18
  • OK, it looks like in Case 2 barList won't get garbage collected as long as there's a reference to it, and the reference will be there as long as the Foo class is loaded, and the Foo class won't get unloaded unless the class loader itself gets garbage collected and a non-user-defined classloader won't get garbage collected. – bez Jul 20 '17 at 18:42

1 Answers1

1

I would rather create a @Singleton bean and let it manage and serves the list. Then you have the following advantages:

  1. the list is initialized only once for the whole application and doesn't have to be static, so you are compliant with EJB standard.
  2. the EJB and the list can be initialized at application startup rather than EJB initialization by means of @Startup and @PostConstruct annotations.
  3. the list can be accessed/manipulated concurrently by using @Lock(READ) @Lock(WRITE).
  4. you can use @Observes pattern in one of your EJB method to react to event and reload the list if needed
Leonardo
  • 9,607
  • 17
  • 49
  • 89
  • I'm using EJB 3.0 and @Singleton was introduced in EJB 3.1. I did end up using a regular singleton though. – bez Aug 01 '17 at 12:29