1

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?

Davio
  • 4,609
  • 2
  • 31
  • 58
  • 1
    You don't have to worry about creating threads - the server will do that for you - but you **DO** have to be aware that everything you write may be accessed by many threads concurrently. – DaveH Feb 13 '15 at 20:08
  • @DaveHowes OP's not worried about creating threads. OP's concern is about synchronizing the shared resources (cache, implemented by `Map`). – Luiggi Mendoza Feb 13 '15 at 20:11
  • there are a lot of questions here! might I suggest you use ehcache which is just a map, but they've done all this worrying for you. – Richard Feb 13 '15 at 20:15
  • @Richard ehcache is more than just a `Map`... – Luiggi Mendoza Feb 13 '15 at 20:16
  • of course. but to all intents and purposes... its just a map. – Richard Feb 13 '15 at 20:27
  • The short article on [JAXB Contexts here](https://jaxb.java.net/guide/Performance_and_thread_safety.html) suggests you do not use a map at all. Different resources can be re-used in different ways to improve a webapp's response time. And before you start optimizing, make sure you know where most time is lost (the 'usual suspects' are I/O related such as database queries). Else it could be a case of [premature optimization](http://c2.com/cgi/wiki?PrematureOptimization). – vanOekel Feb 14 '15 at 01:50

3 Answers3

1

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.

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
  • Read also need to worry about multi threading, for example if he create a stateful servlet it will start sharing important information across sessions. – kamoor Feb 13 '15 at 20:11
  • 2
    I didn't downvote, but what you've written doesn't feel quite right to me. Surely he needs to consider that the objects that he places in his maps have to be threadsafe too. If two threads read the same object from the map and both use it, and that object is not thread-safe, then the behaviour can't be guaranteed can it? – DaveH Feb 13 '15 at 20:12
  • @kamoor definind a stateful servlet is a point of failure and a bad practice. – Luiggi Mendoza Feb 13 '15 at 20:12
  • @DaveHowes that cannot be synchronized. I understand your concern but enters in a different topic. – Luiggi Mendoza Feb 13 '15 at 20:13
  • @LuiggiMendoza Absolutely. I just give one example why he needs to worry about read. Any object shared across sessions needs to be revisited and make sure either it can be shared or synchronized. – kamoor Feb 13 '15 at 20:14
  • Two servlets could, indirectly as an act of trying to marshal something for the first time, both access the map and put something in it. – Davio Feb 13 '15 at 20:14
  • @Davio that falls into: *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*. – Luiggi Mendoza Feb 13 '15 at 20:15
  • @kamoor that's not what OP's asking. Anyway, that's answered here: [How do servlets work? Instantiation, session variables and multithreading](http://stackoverflow.com/q/3106452/1065197) – Luiggi Mendoza Feb 13 '15 at 20:18
1

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

NBW
  • 1,467
  • 2
  • 18
  • 27
0

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!)

Richard
  • 1,070
  • 9
  • 22