Loosing license keys in the DB

Hello,





We seem to have a problem where by the license keys stored in the database table JCHEMPROPERTIES seem be 'lost' or set to zero in the table. We have not pinpointed the exact reason for this yet, but so far it looks as though it might have something to do with 'enabling' a jchem cartridge user.





When the cartridge is installed under the JCHEM user, subsequent users of this cartridge installation seem to hang intermittently. Stopping and starting tomcat does not always solve the problem, and i believe so far the problem only goes away when the cartridge is uninstalled and re-installed. Would re-installing set the license keys back to the correct values?





I am really just wondering if you have seen this problem before, where the license keys are set to zero in the JCHEMPROPERTIES table? Could it be something to do with the 'enabling' of other users and maybe a part of this process we are inadvertantly missing?








JCHEM version 3.0.13, Oracle 10.1.0.3, linux.





Many thanks in advance,


Gemma

Gemma,





Do you use the default JChemProperties table or do you specify one during index creation?





What kind of operations tend to hang? Could you give a few SQL examples? Do you also have to restart the database (or even reboot the machine), or you just reinstall the cartridge? Once one session starts hanging, are all the other users affected or just some of them. Does this seem to be schema specific? How many schema have been enabled to use JChem Cartridge?





Does the hang seem to be linked with license keys being reset? In what way?





Peter

You have been trying to help my collegue Mark (Custom24) recently, the problems he has been having are the ones that I mention here. Unfortunately Mark is on holiday and I do not know all the details.





The reason for posting was because we had a problem today which was to do with loosing the license key values from the default jchemproperties table in the JCHEM schema (the cartidge installation). This happen shortly after another user of this cartridge installation was 'jchem enabled'. i do not know if the keys were missing from the table already or if it happened as part of 'enabling' the other user.





I was just wondering if you had seen this problem before? I'll have to look into it more closely and get back to you if you haven't.





Thanks for the prompt response,


Gemma

I have not experienced this problem yet.

Mark did not mention anything about license keys. If you are sure that you have the same problem as Mark, maybe we could continue the topic started by Mark. Are you referring to this problem:


http://www.chemaxon.com/forum/ftopic751.html


?

I'll discuss this further with Mark when he returns and let you know the outcome.

Gemma,





I feel that the problem with license keys and the problem with hanging sessions is not related.





Because the license keys are stored in jchemproperties tables and the use of multiple jchemproperties table is possible, the registration of license keys may or may not be trivial depending on how you use JChem Cartridge. Therefore an explanation of the mechanisms with jchemproperties tables and license keys might be useful.





As you know, you have the option to associate (during index creation via the JChemPropertiesTable index parameter) a different jchemproperties table with each jc_idxtype index. If you do not specify a jchemproperties table during index creation, the default jchemproperties table will be

Code:

<table-schema>.jchemproperties

where <table-schema> is the schema where the table being indexed is located.





License keys are taken from the jchemproperties table associated with a given jc_idxtype index. This means that if your users (with different schema identities) work on a single structure table, it is sufficient to "register" the license keys only for the jchemproperties table associated with the table's jc_idxtype index -- regardless of whether this jchemproperties table has been associated by default or via index parameter.





On the other hand, whichever jchemproperties table is associated with a given index, the license keys must be registered with that jchemproperties table for the operations on (searches in) the given structure table to use the appropriate licensing information. For example, if you registered the license keys for user A's default jchemproperties table (jchemuser_A.jchemproperties) and user A happens to index a table in schema_B without explicitly associating the table jchemuser_A.jchemproperties with the index via index parameter, then the license keys must be registered for the corresponding jchemproperties table (e.g. the default schema_B.jchemproperties table) as well.





This may or may not be related to your problems with the license keys being "reset", but may be useful to know.





Peter

Gemma,





I made some test with the following scenario:


Users in different schemata continuously issue random substructure queries against the same structure table. While they are doing so, I "enable" new users to use JChem Cartridge. The only problem I encountered was that as I was trying to grant EXECUTE privilege on jchem_core_pkg to the new user, this grant was blocked by ongoing cartridge operations. (The grant command waited for "library cache pin".) If just one user is issuing cartridge commands, the "enabling" procedure completes successfully but eventually with significant delay due to the above mentioned blocking. However, with two "truly" concurrent users the grant on jchem_core_pkg often fails with lock wait time out. With more than two users executing cartridge operation without interruption, "enabling" practically always fails.





I guess you would have noticed any problems of this kind, but you did not mention any. With light load on JChem Cartridge, the "enabling" will not be blocked for a noticeably long time.





Apart from the blocking I did not experience any problem with "JChem-Cartridge-enabling" new users. After "enabling" several new users, the license keys were still present in the jchemproperties table and the old users could still do queries in the structure table.





In order to reproduce the problem (either missing license keys or session blocking), I would need more information about your usage pattern like: how many structure tables are used and in how many schemata they are distributed; are there complex queries involving eventually multiple JChem Cartridge operations on multiple tables; are there any DML operations simultaneously running with the searches...





Best Regards





Peter

After fiddling with Java permissions (as part of testing another problem) not directly related to my test user(s), I sometimes also get errors like this:

Code:

java.sql.SQLException: ORA-29902: error in executing ODCIIndexStart() routine ORA-29549: class SOME.SYSTEM CLASS has changed, Java session state cleared ORA-06512: at "JCHEM30HEAD.JCHEM_CORE_PKG", line 32 ORA-06512: at "JCHEM30HEAD.JC_IDXTYPE_IM", line 140 ORA-06512: at line 1         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:124)         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:304)         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:271)         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:625)         at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:181)         at oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:784)

The permissions I adjusted were not directly related to the user for whom I got this error. (Nor were they directly related to the JChem Cartridge owner whose cartridge this user used.) I am not sure of the exact reason of such errors. For the moment, I suggest to simply ignore this kind of errors in your application and restart the aborted query.





Peter