Alternatives to loading .properties files for every request
I am just starting for a company, and they loading a bunch of .properties files for every request. I've told them that according to JEE specs, using the file system like that is a violation, as it's not scalable. I've suggested the following alternatives:
1. Load a file once, in a static initializer, or something to that effect. Re-start the app if a change needs to be made in properties.
+: few changes
-: requires a new war/ear to make a change
2. Put properties that are truly variable in a database record.
-: requires DB schema change.
3. For instance, i've though about using something like jconsole to change an mbean property, and then web apps using that property.
4. Define a single web app that exposes an EJB/JMS/RMI object which serves properties to other web apps. If a change is needed, only 1 web app needs to be re-started, although it would still have to be re-packaged. Perhaps this app could load this stuff from the DB.
5. Have a properties service, and expose it as an RMI object. If a change needs to be made on the fly, use rmi to make the updates.
I'm leaning towards a combination of 1, 5, and possibly 4.
I would like to know what other alternatives might be available.
Thanks.
[1287 byte] By [
safira] at [2007-11-26 14:29:58]
# 1
> I am just starting for a company, and they loading a
> bunch of .properties files for every request. I've
> told them that according to JEE specs, using the file
> system like that is a violation, as it's not
> scalable.
well, it's just boneheaded that's all
> I've suggested the following alternatives:
> 1. Load a file once, in a static initializer, or
> something to that effect. Re-start the app if a
> change needs to be made in properties.
that's what most people do
> 2. Put properties that are truly variable in a
> database record.
well, databases don't normally hold config info, but you can do what you want
> -: requires DB schema change.
> 3. For instance, i've though about using something
> like jconsole to change an mbean property, and then
> web apps using that property.
> 4. Define a single web app that exposes an
> EJB/JMS/RMI object which serves properties to other
> web apps. If a change is needed, only 1 web app needs
> to be re-started, although it would still have to be
> re-packaged. Perhaps this app could load this stuff
> from the DB.
doing EJB or RMI for getting properties sounds like overkill in the extreme to me
# 2
I guess their main interest is in being able to update .properties and change some values w/o having to re-package the app.
Option 3 might be quite satisfying for that, although will take some coding to accomplish.
Also they have URLs changing from env to env in-house. I think the following would be a good approach to deal w/ that, w/o having to re-package an ear/war for each env:
Refer to a JNDI name in the web app, and specify it in the ear. For WebSphere, the binding appears to go in web-app's WEB-INF\ibm-web-ext.xmi file, so i'm not 100% sure if it can be easily change at deployment time, but i think there's probably a way to do that. For instance, i'm seeing the existing resource reference binding in:
Enterprise Applications > myEAR > Mapping resource references to resources
of admin console. So the admin could change such a JNDI binding after deployment w/o asking the team for a new packaged app. The only question i have on that is whether it's possible to map a JNDI reference to a String (java.lang.Object), rather than a data source or something. I think it should be, but will need to play with it.
# 3
> I guess their main interest is in being able to
> update .properties and change some values w/o having
> to re-package the app.
well you could manually reload it with a button or what not, or you could monitor the directory to see if the file changed/updated, but loading every request is dee dee dee
# 4
> The only question i have on that
> is whether it's possible to map a JNDI reference to a
> String (java.lang.Object), rather than a data source
> or something. I think it should be, but will need to
> play with it.
The first question should be what exactly is the data in question.
For example are you loading US State code abbreviations? One can probably imagine that those are not going to change very often. And a developer/QA can validate them.
On the other hand if you are loading municipalities and tax rates then those are going to change very often. And a business person like an account is the one that needs to validate them.
And how often is the data really used? It doesn't matter if you run 10 transactions a day and each transaction takes an hour to process. Changing the initial load time for properties will doing nothing to impact that at all. On the other hand 10,000 transactions a second would mean something.
The volatity of the data, how it changes, the volume of the data and how it is used all impact the strategy or strategies.
# 5
Hi Safir,
JMX seems like a good fit for managing/tweaking configuration.
You may be interested by this article on Eamonn's blog - which shows how
to implement a DynamicMBean that exposes the content of a property file.
http://weblogs.java.net/blog/emcmanus/archive/2006/11/a_real_example.html
hope this helps,
-- daniel
JMX, SNMP, Java, etc...
http://blogs.sun.com/jmxetc
# 6
Thanks, dfuchs. I'm inclined to that for variable settings too. Perhaps it could be something as simple as
properties.property.reload=1
The only complication is that they are not using Java 5, and using IBM JREs, so chances are this would involve coding a custom MBean client.
P.S. As far as env. configurations, this a great read on the subject, which covers my JNDI references thought of my last post:
http://websphere.sys-con.com/read/47655.htm
I'm inclined to use resource-env-ref for that.
