CODEWITHSUNDEEP
javamultithreadingjakarta-eeservlets
Davio
Davio

Reputation: 4737

How much to worry about threading in Java EE applications?

I have a Java EE webapp with some servlets, JSPs (which are also servlets, right?), SOAP web services (again, servlets?) and REST web services (maybe.. servlets?).

My question is: how much do I have to worry about multithreading? I'm not explicitly creating threads myself, but let the container worry about this.

If I for instance have a cache (static map) of JAXB Contexts for certain classes to make marshalling and unmarshalling faster, do I have to synchronize access to it?

And I also maintain a cache (static map again) of basic XSLT templates used over and over again, same problem?

Upvotes: 1

Views: 252

Answers (3)

NBW
NBW

Reputation: 1487

If you don't need the heavy weight functionality of an entire library / framework like EHCache you can ensure thread safety very easily with the existing / provided JavaEE APIs. Simply create a @Singleton EJB (see link to example below) that uses container managed concurrency to manage access your Map(s) and inject (using @EJB) this EJB into your Servlets or JAX-RS resource. If you need to inject into a JSP you can write a small utility method to look the EJB up since injection annotation doesn't work in JSPs.

1 - Singleton Session Bean Example

Upvotes: 1

Richard
Richard

Reputation: 1130

I just thought I'd add an answer here. As you've hinted at, in java if it does HTTP, the chances are when you get right down to it, it's some sort of servlet yes.

And you don't have to worry about multithreading in terms of load or deadlock etc as long as you follow the rules. As others have pointed out, Servlets are shared between requests. If you put anything into them that holds 'state' (a member variable within the servlet) it will be shared, and could therefore be concurrently accessed. Your maps are definately one of those things.

I suggest you look into EHCache, which is an 'in memory' caching solution ideal for your purposes. At the point of use, it appears just like a Map.

Element element = new Element("key1", "value1");
cache.put(element);

But it manages the entire lifecycle of the object you put in it, when it expires etc. And it also handles concurrency for you. It's what I usually call 'automagic'.

The best thing about EHCache is that you can also use it to scale your application. You could run an identical server, using a round robin load balancer (apache) to choose which server gets the next request, and share the cache between instances. EHCache is loosing ground to other caching mechanisms but in my opinion it's still by far the best solution. And it's ideal for your purpose. (I don't work for terracotta!)

Upvotes: 0

Luiggi Mendoza
Luiggi Mendoza

Reputation: 85779

If your servlets or similar will only use read operations on your shared resources e.g. Map#get(someKey) then there's nothing to worry.

If there is a process in a servlet or similar that can alter the state of your shared resources e.g. Map#put(someKey, someValue) while other resource may be using a reading operation, then yes, you should use synchronization or use a ConcurrentHashMap.

Apart of this, make sure that the state of the objects stored in your cache cannot be altered by clients in order to avoid other problems in your application. Note that these problems (probably) won't raise a ConcurrentModificationException but you will notice the impact.

Upvotes: 1

Related Questions