This one almost counts as a WTF; ever had the feeling that Java Datasources are maybe too restrictive? Ever thought that the JNDI String for your datasource is likely to change from deployment to deployment?

I’m guessing that the answer is a fairly rational “No!” because it just does not make sense to have the JNDI value for a datasource to be located in a config file that is only read when the JVM for an Enterprise application is created. The datasource name may be “hardcoded” but it already serves to decouple the application from the actual database you want to point at.

The application has three schemas within the database and has a variety of Datasources that point to them (XA, regular, 1.4 and earlier). The issue: an analyst cannot save his document definition to the database because the application needs to read a sequence table from a particular schema (less said about the concept of sequence tables the better). Fortunately having encountered this self-same problem before I know that the config controls which datasource is being used and I can check the log to confirm that the application is looking at the wrong schema.

Despite knowing exactly what the problem is and the remedy it still takes over two days to try and figure out which one of the three instances of the application is actually trying to persist the data, find out the config file that is linked to the instance then get the Websphere admin to try restarting various levels of the application server in an attempt to get the damn thing to restart the JVM and re-read the config file.

Well I’m lying actually it took two days for everyone to give up in disgust and just poke the relevant values into the database and leave the problem for the environment owner to try and solve sometime later… Not a professional outcome perhaps but at least the environment owner was actually notified of the issue so its better than normal.

This kind of situations can sour you on Enterprise Java and matches the criticisms of it being over-engineered, unmanagable, awkward to change and difficult to maintain. Yet it isn’t really fair, this issue is about someone wanting to outconfigure the configuration and they ended up creating a configuration option that can only be set or modified when the AS is booted. That probably doesn’t seem a big deal in the development environment where servers tend to yo-yo up and down. Maybe that person was thinking “Wow! I just made the system so much more flexible!” and failed to see the obvious outcome in production because they were just too far removed from it. However I suspect that the real root cause was the “Master of the Universe” syndrome that can sometimes occur in Java programmers, you know that a product has faults, you perceive what you see to be a flaw and you step right into the bear trap.

JNDI strings have an element of lava flow about them, as soon as you’ve defined one then bingo you’re pretty much stuck with it because you’ll never know who was using it if you change it. But, hey, them’s the breaks, you’ve still managed to separate the service from the code and it would have been a lot easier to just correct the configuration of a datasource that it has been to try and work through the JNDI “fix”.