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

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



The normal way I run things is to run opp in a batch file in the source code
directory  with the -KS option and the package root in the path. So I'll
compile-opp-compile to get the final result. The only problems I've found
are that opp will write multiple methods if your inheritance tree has
multiple implementations of a flagged */update*/ method.

So I think you're going to have to do your opp/compile in multiple steps
through multiple directories with the -KS flag on...

Reason
http://www.exratio.com/

> -----Original Message-----
> From: owner-ozone-users@ozone-db.org
> [mailto:owner-ozone-users@ozone-db.org]On Behalf Of Don Berendsen
> Sent: Wednesday, September 19, 2001 11:04 PM
> To: ozone-users@ozone-db.org
> Subject: 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 CLASSPATH=
>
> SET JAVA_HOME=D:\jdk1.3.1_01
> SET INNERVIEW_LIB=D:\innerview\main\innerview-main\lib
> SET OZONE_CLASSPATH=
> SET INNERVIEW_CLASSPATH=D:\innerview\main\innerview-main\src
> SET OZONE_HOME=D:\ozone-1.0.1
>
> echo Initializing Ozone classpath...
>
> set OZONE_CLASSPATH=%INNERVIEW_CLASSPATH%
> set OZONE_CLASSPATH=%OZONE_CLASSPATH%;.
> set OZONE_CLASSPATH=%OZONE_CLASSPATH%;%INNERVIEW_LIB%\xerces.jar
> etc...
>
> OPP is executed using a batch file in the root directory such as:
>
> java -classpath %INNERVIEW_CLASSPATH%;%OZONE_CLASSPATH%
> org.ozoneDB.tools.OPP.OPP -KS
> au.com.harrison.innerview.report.ReportManagerImpl
> au.com.harrison.innerview.report.ReportElementBuilderImpl
>
> Any help would be greatly appreciated.
>
> Thanks,
>
> Don
>
>
> >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
> >the
> >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?
> >
> >Thanks,
> >
> >Don
> >
> >_________________________________________________________________
> >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/
> >----------------------------------------------------------------------
>
>
> _________________________________________________________________
> 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/
> ----------------------------------------------------------------------

----------------------------------------------------------------------
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/
----------------------------------------------------------------------