Re: Thread safety and performance
From: Kevin Fenters (KevinFenters_at_discussions.microsoft.com)
Date: 01/31/05
- Next message: johndoe1: "Re: Q: what is the relation between DB-Lib, OLE-DB, and ODBC?"
- Previous message: Wilsonian: "Querying CSV db with ADO and Jet"
- Next in thread: Sarge: "Re: Thread safety and performance"
- Reply: Sarge: "Re: Thread safety and performance"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 31 Jan 2005 11:47:01 -0800
Sarge
Not sure about commands being more efficient than a rowset, but I would
guess they would be. From your latest post, one thing I would add is that a
prepared command should be agnostic with respect to transactions and you can
serialize as many transactions against a session as you want. I create the
session on starting each thread and keep them open for the duration. The
advantage, in my opinion, of my method is in setting up the buffers and
preparing the command once, and then just calling ICommand::Execute() as many
times as needed after transferring the data to the buffer. I would guess that
it's up to each DB to handle row and page level locking, but a command locks,
writes and unlocks in one call - does it not?
"Sarge" wrote:
>
> "Kevin Fenters" <KevinFenters@discussions.microsoft.com> wrote in message
> news:7992E995-D89A-4BD1-9D7C-D79688FEDCA4@microsoft.com...
> > Sarge,
> >
> > My opinion is that one session per thread is the way to go. OLEDB will
> > support multi-threaded access to a global or static IDBInitialize* in a
> > free-threaded server. I developed a similar thing some time ago, but ran
> into
> > a problem where one thread managed records that the others depended on. If
> > your design creates such a dependency you'll have to serialize multiple
> > threads anyway. If you design it with speed in mind, executing commands
> with
> > parameters is ideal and all that will really happen on executing a command
> > will be to transfer the data into a global or static buffer and calling
> > ICommand Execute. The command, parameters, columns and buffers need only
> be
> > "prepared" once. The same holds true for multiple commands per thread if
> you
> > set them up beforehand and hold them over the lifetime of the threads.
> >
> > Kevin Fenters
> >
>
> Kevin, thanks for your thoughts on this.
>
> I think I can manage the thread serialization by aborting and retrying
> transaction-protected updates and inserts that fail due to locking. I'm
> already used to doing this with Berkeley DB. For example, if you are
> performing an INSERT under ITransactionLocal, it should fail with an
> appropriate HRESULT that tells you another thread has already gained
> ownership of that portion of the table.
>
> So you feel that prepared commands are more efficient than rowsets. I must
> figure out how to reuse prepared commands under transactions. The SDK is
> not clear on the scope of transactions. Supposedly, a transaction only
> applies to the current session, but I don't know if you have to release and
> create the session each time. If so, I would have to prepare all the
> commands again.
>
> --Sarge
>
>
>
- Next message: johndoe1: "Re: Q: what is the relation between DB-Lib, OLE-DB, and ODBC?"
- Previous message: Wilsonian: "Querying CSV db with ADO and Jet"
- Next in thread: Sarge: "Re: Thread safety and performance"
- Reply: Sarge: "Re: Thread safety and performance"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
