Derby database conection - what is the difference between Derby and Derby_net
Hi
I am looking at the ccm/admin and jts/admin pages on RTC 3.0.1.3.
If you look at the JDBC Vendor entry for the data warehouse - jts seems to have DERBY, while the ccm entry has DERBY_NET.
What is the difference between these two entries?
Some context - I have a server with multiple jts/ccm apps running on different tomcat servers on different ports on the same machine. We are problems running the data warehouse jobs and I noticed the following:
1) ccm uses DERBY_NET for the datawarehouse JDBC vendor, while jts uses DERBY for the datawarehouse JDBC vendor.
2) The connection string is along the lines of \\localhost:1527\conf.... in both cases.
To me - this implies that if you are running multiple tomcat instances (and consequently multiple JTS/CCM/DW's) - then a data warehouse job could get very confused when it tried to connect to the DW - which tomcat instance does it really connect to?
thanks
anthony
I am looking at the ccm/admin and jts/admin pages on RTC 3.0.1.3.
If you look at the JDBC Vendor entry for the data warehouse - jts seems to have DERBY, while the ccm entry has DERBY_NET.
What is the difference between these two entries?
Some context - I have a server with multiple jts/ccm apps running on different tomcat servers on different ports on the same machine. We are problems running the data warehouse jobs and I noticed the following:
1) ccm uses DERBY_NET for the datawarehouse JDBC vendor, while jts uses DERBY for the datawarehouse JDBC vendor.
2) The connection string is along the lines of \\localhost:1527\conf.... in both cases.
To me - this implies that if you are running multiple tomcat instances (and consequently multiple JTS/CCM/DW's) - then a data warehouse job could get very confused when it tried to connect to the DW - which tomcat instance does it really connect to?
thanks
anthony
Accepted answer
Hi Anthony,
if I remember correctly this has to do with the Data warehouse. Derby can only run one connection. The data warehouse is used by all applications. So this can not be supported by a standard Derby connection.
As far as I recall we were at a point where Derby could not be supported as a data warehouse DB. Since we wanted to keep this capability something had to be done to fix it.
Now the warehouse DB is run by JTS and the DERBY_NET is a mechanism that allows all other applications to run their data collection jobs etc. against the common warehouse db in case it is Derby.
I am not sure how it works, so I could not comment on the connection string if you use derby in a deployment with multiple machines. Derby should really only be used for demo and test systems. In all other cases I would suggest to use a real database.
if I remember correctly this has to do with the Data warehouse. Derby can only run one connection. The data warehouse is used by all applications. So this can not be supported by a standard Derby connection.
As far as I recall we were at a point where Derby could not be supported as a data warehouse DB. Since we wanted to keep this capability something had to be done to fix it.
Now the warehouse DB is run by JTS and the DERBY_NET is a mechanism that allows all other applications to run their data collection jobs etc. against the common warehouse db in case it is Derby.
I am not sure how it works, so I could not comment on the connection string if you use derby in a deployment with multiple machines. Derby should really only be used for demo and test systems. In all other cases I would suggest to use a real database.
One other answer
It turns out that having mutplie Derby DW's on a single machine is a bad idea. What data gets written to which DW is undefined (ie you could potentially have the wrong data warehouse picking up the wrong data).
Derby has always been regarded as a test database for RTC (as Ralph points out) - and should never used for any kind of production system - esp. not the case I was looking at, where they had multiple instances of RTC (on different app servers and port numbers) where on a single (big) server.
anthony
Derby has always been regarded as a test database for RTC (as Ralph points out) - and should never used for any kind of production system - esp. not the case I was looking at, where they had multiple instances of RTC (on different app servers and port numbers) where on a single (big) server.
anthony