With other applications you can use semaphores for synchronization and
achieve minimal latency and a low overhead.
If you have networked files you are dependent upon the file locking and
on the effectiveness of the cross network file locking. This does not
necessarily work as expected and in particular notorious cases does not
work at all.
If you want maximal performance across a nwetwork you need to implement
a server to manage the database on one machine.
Israel Figueroa wrote:
What if the database is locked by another application, or by another box?
The driver should poll untill it get an "idle database" and then thow an
event... and then, we're polling again.
I'm coding some similar to the original post... I'm not that good with
threads yet, but I did foresee that even with my tiny inserts maybe some
moment I could get a Sqlite_busy. Is that bad just keep inserting until i
get a Sqlite_ok ? Assuming that is not a multiuser enviroment, just one app
accesing the database.
2007/6/1, Ian Frosst <[EMAIL PROTECTED]>:
On the topic of a more efficient busy handler, one approach I considered
was
to implement an event which was signalled when a database unlock
occurred.
That way, the busy handler could just wait on the event (which is an
efficient wait state), and be guaranteed of a wake up when the lock is
released (the event would be signalled at this time.) However, I wasn't
at
the time familiar enough with SQLite's innards to implement such a beast.
Can anyone see any pitfalls to such an approach?
Ian
On 6/1/07, John Stanton <[EMAIL PROTECTED]> wrote:
>
> Tom Briggs wrote:
> >
> >
> >>I don't want to use
> >>other database, because I think Sqlite is great for an
> >>embedded system that I
> >>am using.
> >
> >
> > I think that your own questions about concurrency prove this
> > incorrect. If you need high concurrency and you don't like retries,
> > SQLite is not the database for you.
> >
> > -T
> >
>
> If you require ACID type data integrity and have a single disk there is
> no such thing as a "high concurrency database". They all share a
single
> disk resource in some way. With Sqlite it is up to the designer to
> build in concurrency and that cna be done by single streaming. Better
> performance is achieved by using a single database connection so that
> cache hits are maximized.
>
> If your design is such that you never get a busy then you have an
> effective allocation of your disk resource. Using mutexes between
> threads and semaphores between processes gives you that capability.
>
> To my mind the only time you should use the busy logic is when you are
> working across a network with shared files.
>
>
>
>
-----------------------------------------------------------------------------
> To unsubscribe, send email to [EMAIL PROTECTED]
>
>
-----------------------------------------------------------------------------
>
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
