Singleton to hold collections of rows

Question

In a Web App, need to display a view of 6 objects (rows of table DB) via JSF per page. To advance to the next view another different random 6 objects are to be displayed and so on...

So I was thinking in having a @Singleton that queries all the rows of the table with a @Schedule job in a given interval, let's say every 1 hour. It will have a getCollection() method.

Then every visitor will have a @SessionScoped CDI bean, that will query the Collection of the @Singleton, then shuffle it to make a random view to the specific user.

As with many visits, many CDI beans will be created that will access the getCollection() method concurrently.

Is this thought correctly? Any specific annotations are needed for this case? Any other way of doing this?

-----UPDATE---

After speaking with friends, specially Luiggi Mendoza, they tell me that best thing here is to use a EHCACHE or similar, instead of a Singleon. I think that's the way.

Do you want to implement your own cache library or something similar? — Luiggi Mendoza, Feb 11 '13 at 16:18
Why in earth Quartz if EJB 3.1 has `@Schedule`? See bottom of http://stackoverflow.com/questions/7499534/applicationscope-bean-that-uses-a-timertask-sheduler-good-or-bad/7499769#7499769 — BalusC, Feb 11 '13 at 17:54
@BalusC Because as with `@Singleton`, I've been told to avoid it `@Schedule`, but no real reason behind. — jacktrades, Feb 11 '13 at 18:03

score 5 · Accepted Answer · answered Feb 11 '13 at 16:50

5

Will you have a cluster of webservers? In that case you need a distributed cache or you need to update state through the database.

Else I would just go for a simple map in a bean that is @ApplicationScoped.

I use JPA in a solution where a big bunch of data is almost always the same. There's more then one tomcat involved so a pure cache in a bean that is @ApplicationScoped won't work. To fix it I have no second level cache and instead cache the result of the database queries. That means each tomcat has it's own cache.

For every login a timestamp is read, if the data in the cache is not stale it is used. Otherwise the cache is updated. The timestamp is updated when changes occur with the help of database triggers.

@PrePersist
@PreUpdate
@PreRemove
public void newTimeStamp() {
// save a new timestamp
}

@Singleton is not part of the CDI specification so I would refrain from using it.

Also I would keep my client bean @RequestScoped and reload the 6 objects with @PostConstruct. That way you will get a fresh 6 for every request.

Or if that is to short lived maybe @ViewScoped (requires myfaces codi), @ConversationScoped or @ViewAccessScoped (requires myfaces codi).

answered Feb 11 '13 at 16:50

Karl Kildén

2,415
22
34

Why did you prefer to go to an *@ApplicationScoped* bean instead of a second-level cache? How good does an *@ApplicationScoped* bean handle concurrency? (this is the reason I thought about @Singleton) – jacktrades Feb 11 '13 at 17:15
I could not directly grasp when it would or would not actually read from the database with second level cache. I don't like it. I feel much more in control just caching the result of the queries. That said I never investigated it much. CDI manages concurrency very well ApplicationScoped is no different. You will get a proxy when you inject it. The proxy will always forward the invocation to the correct bean instance, even when multiple threads are accessing a bean at the same time. ApplicationScoped is the singleton of CDI. – Karl Kildén Feb 11 '13 at 19:42
If you are going to do read only I would like to suggest http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/common/collect/ImmutableMap.html or a similar solution – Karl Kildén Feb 11 '13 at 19:43
thx for your help. I think my solution is to use Infinispan which is embedded in Jboss. – jacktrades Feb 11 '13 at 19:45
@jacktrades If you use Jboss I would absolutely go with infinispan. It is to poorly documented for tomcat so I have not tried it myself though. Using Singleton will probably be fine as well using Jboss. This thread has some more information about it: https://community.jboss.org/thread/179642 PS. If I answered the question pls mark as accepted : -) – Karl Kildén Feb 11 '13 at 19:48
Why should @Singleton be avoided since it's not in CDI? Do you also avoid eg the EntityManager because it's not in CDI? – Mike Braun Feb 12 '13 at 18:37
@MikeBraun I read it like the other beans would be CDI managed? What Does JSR-299 say about injecting singletons? iirc it is not clearly defined and implementation specific. Then again hardly relevant for his question. – Karl Kildén Feb 12 '13 at 19:47

Singleton to hold collections of rows

1 Answers1