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

Re: real world examples

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