[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Serious Persistence Problem - new info, ignore previous msg
Thanks Reason & Gerd for your replies.
I suspect the problem isn't caused by where the batch files are run or the
lack of or incorrectly implemented /*update*/ tags in the interfaces.
As I understand the OPP process, the identification of the update methods is
a separate process from the proxy method generation. Apparently the
differences in the implementation of these two processes leads to the
correct methods being generated but with write locks only for those
interfaces in the same directory as the base class.
The "no source file for this interface found" is displayed on line 103 of
the searchUpdateMethods2 method in IfHelper after trying to open the
interface file in the local or output directories. It can never find
interfaces in other directories. Therefore the update methods are not
identified and stored in the hashMap updateMethodsIf for the later proxy
generation process in ProxyGenerator to correctly insert the write lock.
If my understanding of the code is correct this appears to be a bug that
prevents the use of interfaces with update methods in packages other than
the package of the class whose proxy is being generated.
If this is correct and there is a fix for the problem please let me know. If
there is no fix any help in correcting the problem would be greatly
appreciated.
Meanwhile I'll investigate the use of OCD files as suggested by Gerd.
Regards,
Don
>From: "Reason" <reason@exratio.com>
>Reply-To: ozone-users@ozone-db.org
>To: <ozone-users@ozone-db.org>
>Subject: RE: Serious Persistence Problem - new info, ignore previous msg
>Date: Wed, 19 Sep 2001 23:20:48 -0700
>
>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/
>----------------------------------------------------------------------
_________________________________________________________________
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/
----------------------------------------------------------------------