[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Serious Persistence Problem - new info, ignore previous msg

Some additional investigation has clarified the problem. Write locks are 
being generated on methods for interfaces in the same package as the subject 
class whose proxy class is being generated.

Methods for interfaces from other packages are included but only with read 
locks. When OPP is running is gives a message similar to 'can't find source 
code for interface' for extended interfaces from other packages. The update 
methods from these interfaces are not listed during OPP proxy generation. 
Adding the package name to the name of the extended interface does not make 
a difference.

So my question now for other Windoze NT users is:

How do I ensure that OPP can find the source for these interfaces so proxies 
are properly generated?

The package root is in the class path for the OPP execution. I tried adding 
the fully qualified package name to the class path.

I'm starting the OPP process from a batch file located in the directory 
where the source for the classes whose proxies are generated is located. 
This in turn calls a batch file at the package root location.

Prior to running OPP I set up the environment with:


SET JAVA_HOME=D:\jdk1.3.1_01
SET INNERVIEW_LIB=D:\innerview\main\innerview-main\lib
SET INNERVIEW_CLASSPATH=D:\innerview\main\innerview-main\src
SET OZONE_HOME=D:\ozone-1.0.1

echo Initializing Ozone classpath...


OPP is executed using a batch file in the root directory such as:

org.ozoneDB.tools.OPP.OPP -KS  

Any help would be greatly appreciated.



>From: "Don Berendsen" <donberendsen@hotmail.com>
>Reply-To: ozone-users@ozone-db.org
>To: ozone-users@ozone-db.org
>Subject: Serious Persistence Problem
>Date: Thu, 20 Sep 2001 10:28:53 +0800
>Up until the last two weeks we have never had a problem with persistence in
>Ozone. However recently a lot more classes (still only a few 100) and
>objects (a few thousand) have been added to the database and now some
>objects do not persist properly. The object state is changed immediately
>after the method invocation but reverts to its original state after the
>database is closed and reopened.
>We are using the '/*update*/ tag after interface methods to indicate the
>methods that change object state. All the methods associated with the
>problem have the '/*update*/' tag. There is no discernable difference in 
>very few classes & methods where the problem occurs and others. On my
>machine the problem disappeared when I changed the order of loading the
>classes and objects, on another machine the problem continues.
>I noticed in the generated proxies all the method invocations  have a
>Lock.LEVEL_READ. As I recall from earlier days that update methods had a
>Lock.LEVEL_WRITE.  I haven't tested this exhaustively but in one case where
>values weren't persisting I changed the method invocation to
>Lock.LEVEL_WRITE and the value was then persisted properly.
>I'm using Ozone 1.0.1 running on NT4.0, JDK 1.3.1_01.
>Should the invocation of update methods in proxies have a Lock.LEVEL_WRITE?
>If so, how can I compel OPP to generate this?
>if not:
>a. how does Ozone know which methods require a write after invocation?
>b. Is there some setting in the NT, Java, or Ozone environments that could
>be changed to eliminate this problem?
>Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
>Post a message:         mailto:ozone-users@ozone-db.org
>Contact administrator:  mailto:ozone-users-owner@ozone-db.org
>Read archived messages: http://www.ozone-db.org/

Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Post a message:         mailto:ozone-users@ozone-db.org
Unsubscribe:            mailto:ozone-users-request@ozone-db.org?body=unsubscribe
Contact administrator:  mailto:ozone-users-owner@ozone-db.org
Read archived messages: http://www.ozone-db.org/