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

Re: real world examples

The log file shows 0 pending transactions so I don't think it's waiting
for transactions to end.  Also, it commits a good portion of the
name table before it freezes.

Reason wrote:

> The errors I'm getting lead to a freeze if you attempt to shutdown (if it
> lets you get that far :). Ozone declares that it's waiting for transactions
> to end and sits put. Is this the same error output that you get?
>
> (If your geospatial data isn't BLOB-type stuff, you should check out the
> data layer stuff I'm working on. www.twilightminds.com/jdffull.html. I'm in
> the process of [methodically] adding mysql support, so migration paths will
> exist...)
>
> Reason
>
> -----Original Message-----
> From: ozone-users-owner@ozone-db.org
> [mailto:ozone-users-owner@ozone-db.org]On Behalf Of Roy Ladner
> Sent: Thursday, June 21, 2001 10:59 AM
> To: ozone-users@ozone-db.org
> Subject: Re: real world examples
>
> 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