--- In firebird-support@yahoogroups.com, "thefourie2000" <cfourie@...>
wrote:

>
> Related...but on a slightly different topic...The main function for
> the database I'm using is to do selects. It's basically a read only
> db.

Read only or mostly read only? If it is truly read-only, you can use
the gfix tool to make it so.

I know there is no way to disable locking...but is there a lock

> option that will leave the db in the least locked state...if you catch
> my drift. I don't care about threads doing dirty reads because the
> data won't change...

Firebird doesn't lock. It uses record versions so it doesn't have to
lock. With whatever settings two different reads (selects) will never
lock each other. Neither will a write (insert/update/delete) ever
prevent a select.

The only 'lockish' sort of behaviour is where two transactions attempt
to simultaneously write to the same record. Find an article on
Firebird MGA through google.

>
> Would setting the db to read only have an effect on this. Which
> server setup is best for this kind of scenario...multiple processors
> doing loads of reads?

If you have multiple processors, then classic server tends to
outperform superserver. If you have a single processor and the
connections all tend to run the same query, then the shared cache of
superserver will outperform classic. As one of the docs say, if one
was an all out loser, it would not be maintained.

Adam