Multiple cartridge installations?

Hi Peter,





Is it possible to have multiple installations of the JChem cartridge on the same machine? i.e. effectively have multiple cartridge owners?





Cheers





Paul

Hi Paul,





It is possible, but I wonder why you would want that.





Cheers,





Peter

It is down to the design of our application.





It basically needs to create JChem tables dynamically and we also need to run multiple database instances in-house. I cannot get the Oracle .NET data provider to let me log in as SYS to run the scripts (which is the ideal situation). Having multiple cartridge owners is a way around this.





Cheers





Paul

I am trying to understand your motivation so I can better advise you on the setup. In particular, I am not sure whether I have to recommend separate Tomcat installations for each jchem owner or you can get away with just one.





With the current implementation of JChemStreams (the JChem Cartridge components in Tomcat), JChemStreams instances in the same Tomcat share the same configuration. The configuration is stored in the user's home directory, under whose identity Tomcat has been started. If follows that if you have two JChem Cartridge installations in different Oracle instances, you absolutely need two Tomcats, each started as a different user (if running the same machine).





Normally we recommend to use a dedicated Tomcat installation for JChem Cartridge in order to avoid interference with other WEB-applications. A safe generalization of this principle is to say that a dedicated Tomcat installation is recommended for each JChem Cartridge "instance" -- even if the JChem Cartridge "instances" are installed in the same single Oracle instance.





Cheers





Peter

Hi Peter,





I wondered if each JChem cartridge instance might require its own instance of TomCat.





This should only be an issue for in-house users I'm guessing, customers should be able to use the cartridge owner directly.





Cheers





Paul

Hi Paul,

Quote:

I wondered if each JChem cartridge instance might require its own instance of TomCat.

As a general rule, yes, I would recommend to dedicate a single Tomcat instance to a single JChem Cartridge instance.





In addition to the considerations in my previous post, you also have to be aware that each JChemStreams instance (even if deployed in the same Tomcat instance) will use its own structure cache. If you have two JChem Cartridge instances running in the same Oracle instance and operating on the same set of structure tables, you can spare main memory by having the JChem Cartridge instances talk to the same Tomcat/JChemStreams instance. Of course, it depends on the size of your structure tables and the amount of main memory in your machine how compelled you will feel to economize in this respect (http://www.chemaxon.com/jchem/doc/admin/cartridge.html#server_memory).

Quote:

This should only be an issue for in-house users I'm guessing, customers should be able to use the cartridge owner directly.

I am not sure I understand what you mean. Do you mean your customers or ChemAxon's? Or do you have two categories of users: in-house users and "customers"?





I am also not sure I see why you need two JChem Cartridge instances for dynamically creating JChem-tables.





BTW, have you looked at this link: http://www.c-sharpcorner.com/Code/2004/Feb/ODP.NET02.asp: width="90%" cellspacing="0" cellpadding="3" border="0" align="center"> Quote: Privileged Connections





Oracle allows database administrators to connect to an Oracle database server with either SYSDBA or SYSOPER privileges. This is done through the DBA Privilege attribute of the ConnectionString.


The following example connects SYS/SYS as SYSDBA:


// C#


...


OracleConnection con = new OracleConnection();


con.ConnectionString = "User Id=SYS;Password=SYS;" +


"DBA Privilege=SYSDBA;Data Source=oracle;";


con.Open();


...


Is this example not working?





Even, if you are unable to connect as SYS, there must be ways to manage privileges without this ability. For example,


- create a user "jcart_helper"


- create a parametrized stored procedure in SYS schema which calls our jchem_user_hlp.sql scripts


- grant execute privilege to jcart_helper on the stored procedure





When created with the default authid clause (definer), the procedure calling our script is supposed to be executed with the privileges of the user, in whose schema it has been defined (in this case SYS). (Hm... Maybe procedures in the SYS schema are exceptions?)





Cheers





Peter

Hi Peter,

Quote:

I am not sure I understand what you mean. Do you mean your customers or ChemAxon's? Or do you have two categories of users: in-house users and "customers"?

By in-house I mean my collegues, so a less elegant way of doing things is acceptable for them, but not preferable. Obviously for customers, you want the best user experience possible.





With regard to connecting as a user with SYSDBA privs via .NET. The code you have posted is the same that I have been using. It seems the problem (a bit embarrasingly) was that I was using the wrong password! I didn't realise this because I could logon locally using SYS, but not remotely. I assumed (wrongly) it was a security feature. It seems as though Oracle ignores the password when logging into a local db as SYSDBA?

Quote:

Even, if you are unable to connect as SYS, there must be ways to manage privileges without this ability. For example, - create a user "jcart_helper" - create a parametrized stored procedure in SYS schema which calls our jchem_user_hlp.sql scripts - grant execute privilege to jcart_helper on the stored procedure

That is a good idea which I will try.





Many thanks for all your help.





Cheers





Paul

Hi Paul,

Quote:

It seems as though Oracle ignores the password when logging into a local db as SYSDBA?

You might want to look at the section "Operating System Authentication Enabled at Installation" in "Security and Network Integration Guide" (Part No. A95492-01).





BTW, Oracle also has an equivalent feature for Unixes.





Cheers,





Peter