Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

From what I know, the session information is usually saved on the server.
In Java the data is handled as a Map which I guess contains the a String identifier and an object reference which points to a memory zone from the server.

Considering that, is it safe to assume that storing a Properties file on the session will not have a critical effect on performance?

I have to handle some Language Properties files (ResourceBundle). For some reason I have to translate at every request at least 30 strings in one of 3 languages. This results in many conditional clauses which can be avoided by storing the Properties file on the session.

Note: The Properties file is just an example. The aim of the question is to determine why and how placing an Properties object in the session differs from pacing an String object. I am aware of the size aspect but does this issue stands while all Objects are stored on the server?

share|improve this question
add comment

2 Answers 2

up vote 6 down vote accepted

You shouldn't store it in session but at the same time you also shouldn't load the Properties file after each request because of the detrimental impact that repeated file I/O will incur.

Store it on the ApplicationContext which allows the one Properties file to be loaded into memory once and can be used to the beneft of all users on all sessions.

share|improve this answer
    
But it this case I will end up with the 3 files on the context and than I will be forced to make use of those conditional clauses again. The idea was that I would place a file on the session and if any language changes were made by the user than the session file would be updated as well. –  Ionut Feb 10 '12 at 13:03
    
@Ionut I doubt that there are enough conditionals to affect performance detrimentally. What will affect performance is memory usage by inflated sessions or file I/O by reading the properties file on every request. –  maple_shaft Feb 10 '12 at 13:18
    
I am aware that this conditionals will have no large impact on the time performance. The question was aimed to determine if was safe to assume that placing an object in the Session has the same result even if the object is a String or a properties File. –  Ionut Feb 10 '12 at 13:22
add comment

You don't need to code any conditionals to get the appropriate translation for a given property, just a Locale for the current user; provide that when retrieving a ResourceBundle:

ResourceBundle localeSpecificBundle = ResourceBundle.getBundle("bundleBaseName", userLocale);
String translated = localeSpecificBundle.getString("someKey");

In addition, ResourceBundle does some caching through the static getBundle method so that you don't have to worry about doing your own caching to avoid file I/O. From the ResourceBundle doc:

Resource bundle instances created by the getBundle factory methods are cached by default, and the factory methods return the same resource bundle instance multiple times if it has been cached. getBundle clients may clear the cache, manage the lifetime of cached resource bundle instances using time-to-live values, or specify not to cache resource bundle instances.

The actual caching is done with a static ConcurrentMap:

The cache is a map from cache keys (with bundle base name, locale, and class loader) to either a resource bundle or NONEXISTENT_BUNDLE wrapped by a BundleReference. The cache is a ConcurrentMap, allowing the cache to be searched concurrently by multiple threads. This will also allow the cache keys to be reclaimed along with the ClassLoaders they reference.

share|improve this answer
    
Thanks Mike! But I think that in this case a new ResourceBundle will be created at every request am I right? –  Ionut Feb 10 '12 at 13:19
    
Nope; added detail from the ResourceBundle javadoc. –  Mike Partridge Feb 10 '12 at 13:21
    
Thank you! That really helped! –  Ionut Feb 10 '12 at 13:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.