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

Re: real world examples



Our problem appears to be different - we are not using remote database.  We use local
database only.  This is only with 1 thread and it happens at shutdown.

The other unusual thing is that although the program fails to exit, memory is freed
according to the Task Manager in Win2000.  We've let the freeze stand for hours so I
doubt that it's pending garbage collection.

Tim Brown wrote:

> I had the problem of the database freezing at shutdown and traced that to a remote
> database connection I had left open.  I have never get a freeze diring run time and
> I use it pretty heavily.  I have had temporary or short freezes due to garbage
> collection in the JVM running Ozone but those aren't Ozone's fault.
>
> Roy Ladner wrote:
>
> > We're evaluating Ozone for use in storing geospatial data for military
> > applications.
> >
> > I've had similar experience with the server "crashing" - but with single thread.
> >
> > By "crashing" I mean that it simply freezes - no exception and fails to exit.
> > It's happening in WizardStore.commitNameTable() when close() is called on
> > a LocalDatabase instance.  When a transaction is committed, commitNameTable()
> > appears to correctly write all id's and objects, then when close() is called, it
> > freezes
> > about half way through.
> >
> > In my case its random - it will not necessarily occur at the same data twice in
> > a row.
> >
> > Does anyone have any insight?
> >
> > Roy Ladner
> > Naval Research Laboratory
> >
> > Reason wrote:
> >
> > > Annoyingly, it's one of those problems in which turning debugging on and off
> > > changes what actually happens. Oh well. In every case, the server freezes
> > > up; this happens in every run of the test code, even with randomizing of the
> > > order in which operations are performed by the threads. If debugging is on,
> > > the JVM crashes with a stack overflow. If debugging is off, things just
> > > freeze.
> > >
> > > Reason
> > >
> > > -----Original Message-----
> > > From: ozone-users-owner@ozone-db.org
> > > [mailto:ozone-users-owner@ozone-db.org]On Behalf Of Falko Braeutigam
> > > Sent: Monday, June 18, 2001 11:39 AM
> > > To: Reason; ozone-users@ozone-db.org
> > > Subject: RE: real world examples
> > >
> > >
> > >
> > > >
> > > > I'm having considerable difficulty producing a solution for a generic data
> > > > layer with Ozone that is stable under multithreading -- external
> > > > transactions kill me. Or rather, they crash the server for even simple
> > > > applications providing that the threads are following one another closely
> > > > enough.
> > >
> > > Hmmm... so there must be some kind of race condition inside the
> > > ExternalDatabase code.
> > >
> > > What does this mean "crash the server"? Do you have a stack trace or
> > > something?
> > > I never, under no circumstances, saw an ozone server actually "crash"
> > > (actually
> > > stop execution), with the exception of JVM crashes.
> > >
> > > ______________________________________________________________________
> > > Falko Braeutigam                              mailto:falko@smb-tec.com
> > > SMB GmbH                                        http://www.smb-tec.com