Re: [sqlite] Berkeley DB vs. SQLite for threaded application

[Tomas Lee]

On 2008 January 16 (Wed) 04:57:42am PST, [EMAIL PROTECTED] wrote:
> Tomas Lee <[EMAIL PROTECTED]> wrote:
> > I've got an application that has Berkeley DB embedded in it.  I want
> > to replace Berkeley DB with SQLite.  (I plan to use the 3.5.4
> > almagamation, which is the latest I could find.)  The thing is, this
> > application uses threads.  I know threads are evil, but this
> > application uses them, and there it is.  So, I wanted to understand
> > what I had to do to be safe.
> > 
> > As I understand it, Berkeley DB has free-threaded database handles, so
> > my application can open a Berkeley DB database connection and have all
> > of its thread use that same connection.  But SQLite doesn't allow
> > this, so I'm going to have to change things.  In theory, I could just
> > open and close a new connection whenever I want to access the
> > database.  How much a performance hit is that?
> > 
> 
> As of version 3.5.0, SQLite allows free-threaded database handles.

Ah!  That makes things a lot easier.  Thanks!

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Berkeley DB vs. SQLite for threaded application

[drh]

Tomas Lee <[EMAIL PROTECTED]> wrote:
> I've got an application that has Berkeley DB embedded in it.  I want
> to replace Berkeley DB with SQLite.  (I plan to use the 3.5.4
> almagamation, which is the latest I could find.)  The thing is, this
> application uses threads.  I know threads are evil, but this
> application uses them, and there it is.  So, I wanted to understand
> what I had to do to be safe.
> 
> As I understand it, Berkeley DB has free-threaded database handles, so
> my application can open a Berkeley DB database connection and have all
> of its thread use that same connection.  But SQLite doesn't allow
> this, so I'm going to have to change things.  In theory, I could just
> open and close a new connection whenever I want to access the
> database.  How much a performance hit is that?
> 

As of version 3.5.0, SQLite allows free-threaded database handles.
--
D. Richard Hipp <[EMAIL PROTECTED]>


-
To unsubscribe, send email to [EMAIL PROTECTED]
-

Re: [sqlite] Berkeley DB vs. SQLite for threaded application

[RaghavendraK 70574]

I would suggest you to go for thread specific sqlite handles.
This would make each thread operate in its own db connection handle.

threadID = getthreadID();
if(threadIDHashList.find( threadID)== false)
  {
//new thread,just add this threadID to list
//create new DB connection and save it as part of TSD*threadspecific data.
  }

regards
ragha
**
 This email and its attachments contain confidential information from HUAWEI, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
delete it!
 
*

- Original Message -
From: Tomas Lee <[EMAIL PROTECTED]>
Date: Wednesday, January 16, 2008 12:54 pm
Subject: [sqlite] Berkeley DB vs. SQLite for threaded application

> I've got an application that has Berkeley DB embedded in it.  I want
> to replace Berkeley DB with SQLite.  (I plan to use the 3.5.4
> almagamation, which is the latest I could find.)  The thing is, this
> application uses threads.  I know threads are evil, but this
> application uses them, and there it is.  So, I wanted to understand
> what I had to do to be safe.
> 
> As I understand it, Berkeley DB has free-threaded database 
> handles, so
> my application can open a Berkeley DB database connection and have all
> of its thread use that same connection.  But SQLite doesn't allow
> this, so I'm going to have to change things.  In theory, I could just
> open and close a new connection whenever I want to access the
> database.  How much a performance hit is that?
> 
> <http://sqlite.org/faq.html> tells me that I can move a connection
> handle across threads as long as that connection is holding no fcntl()
> locks, and that this is due to fcntl() bugs on some OSes, like 
> RedHat9.But what if I'm running on an OS that doesn't have these 
> bugs -- do
> I have to worry about moving a connection handle across threads?  And
> how can I tell if my OS has these bugs?
> 
> ---
> --
> To unsubscribe, send email to [EMAIL PROTECTED]
> ---
> --
> 
> 

-
To unsubscribe, send email to [EMAIL PROTECTED]
-

[sqlite] Berkeley DB vs. SQLite for threaded application

[Tomas Lee]

I've got an application that has Berkeley DB embedded in it.  I want
to replace Berkeley DB with SQLite.  (I plan to use the 3.5.4
almagamation, which is the latest I could find.)  The thing is, this
application uses threads.  I know threads are evil, but this
application uses them, and there it is.  So, I wanted to understand
what I had to do to be safe.

As I understand it, Berkeley DB has free-threaded database handles, so
my application can open a Berkeley DB database connection and have all
of its thread use that same connection.  But SQLite doesn't allow
this, so I'm going to have to change things.  In theory, I could just
open and close a new connection whenever I want to access the
database.  How much a performance hit is that?

 tells me that I can move a connection
handle across threads as long as that connection is holding no fcntl()
locks, and that this is due to fcntl() bugs on some OSes, like RedHat9.
But what if I'm running on an OS that doesn't have these bugs -- do
I have to worry about moving a connection handle across threads?  And
how can I tell if my OS has these bugs?

-
To unsubscribe, send email to [EMAIL PROTECTED]
-