Hi,

I've used .fdb extension since I began using XP and I see this behaviour
with .fdb extension.
I planned to investigate this at some point - but havent done so yet and so
also am unaware of
exactly where it occurs - although it seems to be on first db access and
gets longer as the database
grows - the hd light stays on continously - and it seems to fo for long
enough to have loaded all the
pages in the database.

But this does not happen every time it starts - but I have not seen a
corelation between this and restarting
windows but I havent been looking.

> Crash recovery - no. It doesn't do it because it doesn't need to.

I guess that counts out that hypothesis.

Perhaps I am running a query which ends up needing to visit many pages in
the db and these end up getting cached by
OS so removing the cost of loading these on susequent start up - I will need
to investigate this to really find out.

>In normal client/server mode, it's the server that opens the file and gets
>the exclusive lock, so it will be the first user to log on who experiences
>the delay.

The database is only accessed by the app and there is only one instance of
the app. So when the app closes all the connections to the DB(which I guess
should occur on the server because the process owning the socket is closed)
I guess it should cause the server to close the file - so in that respect it
should be the same.

But when in client/server mode the server actually has a chance to close the
file - whereas in embedded mode the server process just disappears - which
is what led to my previous hypothesis.

I cant be 100% sure that it only occurs with embedded server though. Basicly
I need to investigate this - I had just realised I had similar thing
happening and that was what I though might be the cause.

Whats reassuring though is that I(and many of my coluges) have routinley
killed the app(currently it ends up just doing a system.exit() - a more
controlled shutdown procedure would be good but it needs to be able to
recover under all circumstances anyway) with embeded server many many times
during heavy database access and have never seen a corrupt database or data
loss.

Thanks
Ryan

-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: 16 July 2003 16:38
To: Firebird-Java@yahoogroups.com
Subject: RE: [Firebird-Java] Strange initial startup behavior


At 01:44 PM 16/07/2003 +0100, you wrote:

>Hi,
>
>I have noticed similar behaviour with my applications - although I only
>noticed it when starting to use embedded server.
>
>I was wondering if it may in my case be because the database server(being
>embedded in the application) does not cleanly
>disconnect from/shutdown the database(I currently still have connections
>open when the app exists) and then when next
>starting needs to do some kind of crash recovery ?

Crash recovery - no. It doesn't do it because it doesn't need to.

But - if you are on XP or WinME then the fact that you didn't notice the
effect until using embedded server would be explained by the fact that
SystemRestore does its dirty deed each time the file is opened. Because an
embedded app gets an exclusive lock on the database file, you'll literally
get a SystemRestore every time you open your app.

In normal client/server mode, it's the server that opens the file and gets
the exclusive lock, so it will be the first user to log on who experiences
the delay.

Helen

NB Ryan, since I wasn't sure you actually read down as far as my comment,
I've left it here (below).

-----Original Message-----

>From: Helen Borrie [mailto:helebor@...]
>Sent: 16 July 2003 00:11
>To: Firebird-Java@yahoogroups.com
>Subject: Re: [Firebird-Java] Strange initial startup behavior
>
> >But thats no solution for my Win32-Application-problem :( .
> >
> >Any ideas how 2 avoid this initial startup procedure/file scan ?
>
>Noting the discrepancy between Linux and Windows that you report, my guess
>is that you are using WinXP or WinME and have a database file with a ".gdb"
>extension. If this is the case, try renaming the file with ".fdb"
>extension and see whether it changes the behaviour.
>
>See the Firebird 1.0 release notes for an explanation.
>
>Helen

To unsubscribe from this group, send an email to:
Firebird-Java-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/