JDO Cant handle more then one jdo-conf

Found out the problem is at the JDOConfLoader class where it can only handle one
jdo configuration, ever. This should be changed to be able to handle multiple,
escpeically in enterprise level apps, i can see many different database
connections needed.

Or, have a support for multiple database, but then it comes down to the
Transaction stuff and setting that up.

• • • This bug has been marked as a duplicate of 1594 ***

Nick, your observation is correct, as the JdoConfLoader has been introduced my
myself when dealing with the transaction manager changes. I do not have any
means of accessing the code in a meaningful way here at work, but I do have a
feeling that JdoConfLoader might be using a static variable to store one
configuration only.

If that's the case, one might simply change this to using a java.util.Map keyed
on the database name.

Well I'm ahead of you by a little bit (stared at it for a couple hours
yesterday ). You are right that it uses a static field for the conf and that
a map will fix the problem. The issue with the map is that it wont be safe to
go off the database name, because you might have the same database name in two
different config files.

Soooo, with that being said I've made changes to allow named jdo
configurations. Right now I have it done in code, however it might make more
sense (just thinking about it) to have it in the actual jdo file. Maybe a
required attribute such as 'name' in the <jdo-conf> tag. Or something like
that.
I'll submit a patch of what i have a bit later so you can tell me what ya
think. It touches a few files and dont know if it works 100%, but it does at
least work for what I've been doing.

Created an attachment (id=665)
First draft of patch

You can see above what I did do compensate for the 'named' jdo files. Like I
said before this method appears to work, but I think it would be ALOT cleaner if
done in the xml file.

Anyways, this is just for some ideas/comments. Let me know what you folks think.

Nick, can I ask you a question before assessing the patch. You are in the end
asking for a new feature to be implemented, correct. Afaik, Castor so far didn't
have support for multiple configuration files to be used, right ? And does this
make sense at all ? Shoudln't a user be required to create two separate JDO
instances for such business ?

9.5.3 does support mulitple config files and I used that feature quite a bit.
Thats how I actually ran into this problem when I was trying to convert over to
the latest version of Castor.

But i think there is another problem that you are missing. Its that I am indeed
trying to make 2 new JD0 instance (one for each config). But how it is right now
thats not possible. Well the 2 JDO instances are, but not with seperate config
files. So I agree with you there.

> But i think there is another problem that you are missing. Its that I
> am indeed trying to make 2 new JD0 instance (one for each config). But
> how it is right now that's not possible. Well the 2 JDO instances are, but
> not with seperate config files.
Just to confirm this, as I have never used this feature. What you want(ed) to
do, is along teh lines of

JDO jdo1 = new JDO ("dbName1");
jdo1.setConfiguration ("jdo-conf.1.xml");
Database db = jdo1.getDatabase();

JDO jdo2 = new JDO ("dbName2");
jdo2.setConfiguration ("jdo-conf.2.xml");
Database db = jdo1.getDatabase();

Well yes except the second database should be:

Database db = jdo2.getDatabase();

Thats exactly what I want to be able to do, and did do during the last release.

Nick, FYI, I have prepared a patch for bug 1594 that adresses this problem
partially, in that it re-enabled you to specify more than one <database>
element in the JDO configuration file.

I saw the notes on that bug. I haven't been able to test it out yet, but will
try and do so in short order.

Thanks, Nick. When doing so, please keep in mind that if you specify multiple
database instances, using the same name is still a no-no. There's one more bug
out there that provides a better home for such a 'new' request.

If you still fancy, could you please provide me with a new patch that builds
upon the features added by bug 1594, so that we can discuss things without
looking at so many old (and resolved) issues.

I'll see if I can come up with anything for this. I think with the new JDO2
class and its mechanisms it should be easier to implement this. I'll take a look
into and see whats going on.

Ok, looking through the new JD02 class I have an idea an what to do, but am
looking for some input and clarifacation.

Right now there is, at least to me, an artifical limitation that any JDO conf
file you pass it has to share; the same class loader, the same input source(Doh!
thats not going to work!!), and the same EntityResolver. Plus. you could not
have the same database name in multiple conf files, as the map for the databases
is also static.

I'm also confused by the fact that we are storing what we are calling the JDO
configuration, but its not really that, its really just the particular Database
configuration WITHIN a particular JDO2 configuration. (loose you yet?)

The whole JD02 (name) thing is confusing as well, and goes along with the above.
Again, we are storing the JDO2 conf with a database conf name. Why do this when
we have a Database object that we should store with a database conf name.

The database registry should, and looks like it can, hold a lot of this info.
This should be seperated out more, and the JDO conf should be tied less to the
under lying database confs.

Ok, I think I've gone and confused everyone by now....please comment and ask
questions. I know what I'm trying to say, believe me.

Created an attachment (id=952)
Test case loading 2 jdo-conf.xml files and creating JDO2 instances

Created an attachment (id=953)
Very simple patch that solves problem of above test

In addition to loading multiple jdo-conf's we should also be able to unload them
if they are not needed any more.

• • • Bug 1878 has been marked as a duplicate of this bug. ***

Created an attachment (id=985)
Additional test case to load jdo-conf.xml in various combinations.

I forgot to tell you that I found out that attachment 953 don't solve the
problem but leads to an exception at a later point of execution.

Gentlemen,

are we any closer to a workable solution for multiple Castor configurations for Castor JDO 0.9.6 ?

We are also using multiple Castor configuration files, representing multiple data sources / databases. This feature was supported in Castor JDO 0.9.5.3, as noted by Nick Stuart, but has been lost with the release of Castor JDO 0.9.6.

I noticed there was a change to JdoConfLoader to support multiple "database" elements per "jdo-conf" element in the "jdo-conf.xml", but this does not appear to be reflected in the Castor DTD. Should we look to declaring multiple databases per global Castor configuration file ?

Comments and suggestions welcome.

Tim.

As suggested on the user mailing list we should check if there are possibilities to shutdown/close resources we requested/opened.

Patch for review. Take care as the loading of multiple jdo-conf only works with JDOManager and not with JDO.

Tim, Nick, can we please hear your views ? I have just tried Ralf's patch, and it seems to resolve the issue discussed. Though it still should be specified what happenes if we load a configuratio ntwice. Currently, the 'old' configuration under the same name id overwritten, and a small debug message is appended to the logs. Is this what you wanted ?

Werner, Ralf, I think that will work out. I cant think of any reason why I, or anyone, would need 2 instances of the same JDO file available and would probably lead to other nightmares down the road. I think just being able to have seperate instances of the JDO conf is fine given the fact that they are different files.

I haven't had a chance to test this out yet (as I've moved to all one jdo-conf with multiple databases) but I will try it out.

Also, has the DTD been changed for Tim's comment about it showing that only 1 database element is allowed? Haven't checked myself.

The DTD allows multiple "database" elements per "jdo-conf".

As there are no negative comments regarding the overloading of a configuration loaded twice, I proceed with commiting the patch.

Patch commited as is.