views:

50

answers:

2

My understanding of JDBC is that it automatically sets the Oracle NLS_LANGUAGE/NLS_TERRITORY session parameters based on the default Locale of the JVM. This is handy for a stand-alone swing app, but seems useless for a java webapp. The only solution I can come up with is to specifically set the session parameters right before actually doing a database query, something similar to:

Connection c = // However you get it.
Statement s = c.createStatement();
s.execute("alter session set NLS_LANGUAGE = 'SPANISH'");
// Do actual query here

My questions:

  1. Is this the best way to set the Oracle language/country parameters from a webapp?
  2. Since the Oracle parameters take language names rather than codes, is there a mapping from java/ISO language codes to Oracle language names? For example, can I use Locale.getDisplayLanguage() and be safe?
A: 

If you're using connection pooling, it's the best way to make sure that Johnny's results are in American and Johann's results are in German.

You could store the user's preferred NLS value for LANGUAGE, TERRITORY, CHARACTERSET, and SORT, using V$NLS_VALID_VALUES as a data source, assuming you store login/user information.

Adam Musch
Thanks for your comment, I am a bit confused about "users" here - every web app I've ever worked on (across four companies) only has one user, which is the application itself: individual users do not have logins to the database. Do your webapps use a different set up? What really confounds me, though, is that I can't find anything on the internet that addresses this question. Doesn't every internationalized webapp run into the same problem? Am I missing something?
fool4jesus
Lots of applications have a single "database" user who connects to the back end, but a different "context" user to ensure that Alice doesn't change Bob's account balance. And yes, i18n/l10n (internationalization / localization) is a huge problem that isn't handled well even by multinationals doing enterprise grade software.
Adam Musch
A: 

Can depend on your architecture.

Some places opt to have multiple geographically local web-apps against a single database (ie one in the France, one in the UK, one in Spain).

Or you pull data (eg dates, numbers) in 'computer' format from the database and have the web-app convert it to the end-user's preferences (or possibly based on browser information if you don't have user logins).

Or you have separate connection pools for different 'territories'.

Bear in mind that queries changing territories can affect index usage and sorting.

Gary