User 0b0faeb478
01-03-2007 20:15:20
Hi
Sorry to post this again. I posted in a wrong forum earlier.
I have a question on installing JChem Cartridge for Oracle RAC. Since there is a requirement for Apache Tomcat for the installation, I was wondering how to go about.
We have two nodes for Oracle RAC and am wondering how to install Tomcat on the nodes. Do each of the node will have tomcat installed if Tomcat were to be installed on the nodes of the Oracle RAC?
OR can Apache Tomcat live on a different machine and connect as a client for the Oracle RAC using tnsnames file?
Please advice. If you have any other recommendation I would love to hear from you.
Thank you
ChemAxon aa7c50abf8
01-03-2007 21:24:21
Hi,
In general, Tomcat doesn't have to be on the same machine as Oracle.
There are basically two requirements:
(1) Oracle (Java) stored procedures must be able to make http requests to Tomcat (through the domain name or IP address of the machine hosting Tomcat);
(2) Tomcat must be able to open database connections to Oracle (not through tnsnames, but through ip address [or domain name], listener port number and SID -- parameters which can be configured using the HTML based admin GUI described in the installation guide).
I've never tested JChem Cartridge in a RAC (and, to be honest, I don't know very much about RAC apart from what this abbreviation stands for).
Tomcat is, in the context of the second condition, a mere database client, so condition (2) is almost certainly met with RACs. I am not so sure about condition (1), but if stored procedures can do the same things in RACs as with stand-alone Oracle installations, I don't see apriori any reason why this condition shouldn't be met.
Let me know how you get on.
Cheers
Peter
ChemAxon aa7c50abf8
27-03-2009 10:02:17
We have tested JChem Cartridge with Oracle RAC using JChem 5.2.0 with JChem Server running on a separate server -- "outside" the cluster. Please, see the installation instructions here:
http://www.chemaxon.com/jchem/doc/admin/cartridge.html#oracle_rac . Note that with Oracle 10g2, patch-level 10.2.0.4 is required.
Work is in progress to eliminate a minor issue with the configuration in which each cluster node has its own JChem Server.
Thanks
Peter
User a7faa21887
17-10-2011 16:04:00
pkovacs wrote: |
We have tested JChem Cartridge with Oracle RAC using JChem 5.2.0 with JChem Server running on a separate server -- "outside" the cluster. Please, see the installation instructions here: http://www.chemaxon.com/jchem/doc/admin/cartridge.html#oracle_rac . Note that with Oracle 10g2, patch-level 10.2.0.4 is required.
Work is in progress to eliminate a minor issue with the configuration in which each cluster node has its own JChem Server.
|
Hi,
Is it work completed?
It will be very useful for our 3-node 11gR2 RAC. We cannot use separate server to run JChem Server.
Also I want to ask: if I have more than one schema (application) in single database:
- do I have to run separate JChem Servers for each schema (application) on different ports?
- do I have to configure different values for structure.cache.id for such servers?
- is it possible to place JChem server into Clusterware control?
Pavel
P.S. I can test any cases to help you complete documenting such usage of JChem in RAC environment.
ChemAxon aa7c50abf8
17-10-2011 17:23:05
Is this work completed?
The facility is in place, but it has not been extensively tested. The key to making use of it is that if the JCC server is configured to use the "parent" session's identity to connect back to Oracle (as described under http://www.chemaxon.com/jchem/doc/admin/cartridge.html#jcserver_dbaccess_credentials), the two-argument version of the use_password procedure has to be used: jchem_core_pkg.use_password(login VARCHAR2, password VARCHAR2). With his procedure, the password will be always sent over to the JCC server along with the request, so if the session gets switched-over to a different node, the JCC server dedicated to the node will not run into a "cache-miss" for a user it has never serviced before. (The scheme whereby default, pre-configured user-credentials are used to connect back to Oracle should work without modification.)
Regardless of the authentication scheme, the general points about setting up one JChem Server for each RAC node are:
1. Both JChem Server and the Oracle-resident part of JChem Cartridge have to be configured to use "localhost" to communicate with each other (i.e. the url property must not be specified in jcart.properties);
2. A different (unique) structure cache id must be provided for each JChem Server.
do I have to run separate JChem Servers for each schema (application) on different ports?
If the JCC instances in the different schemata are of the same JChem version, you don't have to. (With different JChem versions, multiple JCC servers are needed.) There is, however, a constraint with using multiple JCC instance in the same Oracle intance unrelated to JCC configuration: one user can use exclusively one of the JCC instances. The JCC instance which will be used by a given user is defined by the synonyms for the JCC objects the user sees. By default, the JCC installation sets up public synonyms to the JCC instance it is installing (e.g. synonyms for objects in the JCHEM schema). If a user wants to use the JCC instance installed in JCHEM_NEW, private synonyms have to be created using the privman_pkg.syns_for_jcobjs(jchemowner varchar2); procedure.
do I have to configure different values for structure.cache.id for such servers?
You have to use a different structure.cache.id for each JCC server accessing the same Oracle instance.
is it possible to place JChem server into Clusterware control?
I am not entirely sure what all this involves, but I am afraid it is not currently possible.
Peter
User a7faa21887
17-10-2011 18:02:55
Thanks a lot, Peter.
pkovacs wrote: |
Is this work completed?
The facility is in place, but it has not been extensively tested. The key to making use of it is that if the JCC server is configured to use the "parent" session's identity to connect back to Oracle (as described under http://www.chemaxon.com/jchem/doc/admin/cartridge.html#jcserver_dbaccess_credentials), the two-argument version of the use_password procedure has to be used: jchem_core_pkg.use_password(login VARCHAR2, password VARCHAR2). With his procedure, the password will be always sent over to the JCC server along with the request, so if the session gets switched-over to a different node, the JCC server dedicated to the node will not run into a "cache-miss" for a user it has never serviced before. (The scheme whereby default, pre-configured user-credentials are used to connect back to Oracle should work without modification.)
|
I prefer use encrypted oracle.server.password and
oracle.server.login as described on your link at
Defaulting to a pre-configured identity section (I already use it). I think it's more secure.
pkovacs wrote: |
Regardless of the authentication scheme, the general points about setting up one JChem Server for each RAC node are:
1. Both JChem Server and the Oracle-resident part of JChem Cartridge have to be configured to use "localhost" to communicate with each other (i.e. the url property must not be specified in jcart.properties);
2. A different (unique) structure cache id must be provided for each JChem Server.
|
1. It's not possible - I'll replace it with VIP, ok? (that's why I was ask about Clusterware)
2. Ok, I see
do I have to run separate JChem Servers for each schema (application) on different ports?
If the JCC instances in the different schemata are of the same JChem version, you don't have to. (With different JChem versions, multiple JCC servers are needed.) There is, however, a constraint with using multiple JCC instance in the same Oracle intance unrelated to JCC configuration: one user can use exclusively one of the JCC instances. The JCC instance which will be used by a given user is defined by the synonyms for the JCC objects the user sees. By default, the JCC installation sets up public synonyms to the JCC instance it is installing (e.g. synonyms for objects in the JCHEM schema). If a user wants to use the JCC instance installed in JCHEM_NEW, private synonyms have to be created using the privman_pkg.syns_for_jcobjs(jchemowner varchar2); procedure.
I think we need to use different versions of JChem in the same database - for trunk and for release version, for example. So. I'll try to use privman_pkg.syns_for_jcobjs(jchemowner varchar2); procedure.
I see all other information.
Thanks a lot (as usual)
ChemAxon aa7c50abf8
18-10-2011 22:15:18
I'll replace it with VIP, ok?
Yes, this should work as well.
Peter
User a7faa21887
21-10-2011 05:44:57
Hi
As I understood from experience,
Running JChem Server on all RAC nodes is useless, because JC_IDX_PROPERTY table in JChem Cartridge owner (jchem, by default) contains only single hostname to connect to JChem Server and single JCC name.
So, Is it possible use next environment to provide some kind of load balancing and high availability:
1. Run JChem Server on each RAC node
2. Use SCAN host for Oracle 11g RAC to place in JC_IDX_PROPERTY. SCAN have several IP-addresses with "round robin" select method between them. It will connect oracle sessions to any running JChem Server on these IP-addreses
3. Use single name for JCC for all JChem Servers running on each node
Pavel
ChemAxon aa7c50abf8
21-10-2011 07:05:32
Hi Pavel,
Running JChem Server on all RAC nodes is useless, because JC_IDX_PROPERTY table in JChem Cartridge owner (jchem, by default) contains only single hostname to connect to JChem Server and single JCC name.
You should be able to set "localhost" or "127.0.0.1" (or "::1" for IPv6) for the JChem Server's hostname in the JC_IDX_PROPERTY table. Just make sure the JChem Servers advertise the same "name" in their jchem.server.host properties.
Let me know if you encounter any problem with this.
Thanks
Peter
User a7faa21887
21-10-2011 08:06:05
O, I see, Peter, now.
I can use any abstract hostname (as well hostname) in JC_IDX_PROPERTY with different resolve in local /etc/hosts files.
I didn't think about it. Thanks.
What about JCC name? I have to use the same JCC name (as wrote in JC_IDX_PROPERTY too) for all nodes?
ChemAxon aa7c50abf8
21-10-2011 08:54:18
I can use any abstract hostname (as well hostname) in JC_IDX_PROPERTY with different resolve in local /etc/hosts files.
I am afraid I do not fully understand what you mean. Generally speaking, the host name must be resolvable on the client host (which is in this case the Oracle Server) ...either through the /etc/hosts file or a DNS server or a NIS server...most operating systems support multiple ways to resolve hostnames. (On Linux, the "ueber-configuration" of host name resolution is done in the "hosts" entry in the /etc/nsswitch.conf file.)
Perhaps, the best would be to start with 127.0.0.1 to avoid the extra complexity associated with name resolution.
What about JCC name? I have to use the same JCC name (as wrote in JC_IDX_PROPERTY too) for all nodes?
Do you mean the structure.cache.id property in JC_IDX_PROPERTY? This is actually a semi-colon-separated list of the cache-ids as configured for the individual JChem Cartridge servers in their respective jcart.properties files. E.g. if you have two JCC servers with cache id JCC1 and JCC2 respectively, the structure.cache.id property in JC_IDX_PROPERTY should read: JCC1;JCC2 .(The cache id is used to make sure that all JChem Cartridge servers connected to the Oracle service are notified of structure INSERTS/UPDATEs, so all of these JCC servers update their cache with the changes in the database.)
Peter
User a7faa21887
21-10-2011 16:50:18
pkovacs wrote: |
I can use any abstract hostname (as well hostname) in JC_IDX_PROPERTY with different resolve in local /etc/hosts files.
I am afraid I do not fully understand what you mean. Generally speaking, the host name must be resolvable on the client host (which is in this case the Oracle Server) ...either through the /etc/hosts file or a DNS server or a NIS server...most operating systems support multiple ways to resolve hostnames. (On Linux, the "ueber-configuration" of host name resolution is done in the "hosts" entry in the /etc/nsswitch.conf file.)
Perhaps, the best would be to start with 127.0.0.1 to avoid the extra complexity associated with name resolution.
|
Hi. Sorry, my post was not so clear as I thought.
I mean that I can the same hostname, i.e. jchem-server.myhost.com, but assign to it different IP-addresses in /etc/hosts file:
/etc/hosts on node0:
10.1.1.1 jchem-server.myhost.com
/etc/hosts on node1:
10.1.1.2 jchem-server.myhost.com
P.S. I don't like use localhost because it's no so clear as real names in hostnames. Also in future I can easy move JChem Server to another node or anywhere outside RAC without change anything in database parameters.
|
What about JCC name? I have to use the same JCC name (as wrote in JC_IDX_PROPERTY too) for all nodes?
Do you mean the structure.cache.id property in JC_IDX_PROPERTY? This is actually a semi-colon-separated list of the cache-ids as configured for the individual JChem Cartridge servers in their respective jcart.properties files. E.g. if you have two JCC servers with cache id JCC1 and JCC2 respectively, the structure.cache.id property in JC_IDX_PROPERTY should read: JCC1;JCC2 .(The cache id is used to make sure that all JChem Cartridge servers connected to the Oracle service are notified of structure INSERTS/UPDATEs, so all of these JCC servers update their cache with the changes in the database.)
Peter
|
Yes, I meaned structure.cache.id property.
It's interesting. I probably missed this in documentation.
Thanks, Peter.
ChemAxon aa7c50abf8
24-10-2011 10:21:33
Hi Pavel,
I mean that I can the same hostname, i.e. jchem-server.myhost.com, but assign to it different IP-addresses in /etc/hosts file
One of my tips about what you might have meant was something along those lines, I just was not sure. :-) Thank you for the clarifcation.
I probably missed this in documentation.
The format of the structure.cache.id property in JC_IDX_PROPERTY is actually not documented. install --jcserver-only is supposed take care of that property "behind the scenes" (i.e. by adding the specified cache id to the list in JC_IDX_PROPERTY).
Peter