Kjell Rilbe schrieb am 24.01.2011 um 04:24 (+0100):

> Michael Ludwig skriver:
> > ma_golyo schrieb am 21.01.2011 um 13:54 (-0000):
> > >
> > > From the documentation : "The client libraries, including the
> > > embedded one, can now be used in multi-threaded applications
> > > without any application-level synchronization." What does this
> > > exactly mean?
> >
> > > #1 : Can I use only a single connection accessing by multiple
> > > transactions from different threads at the same time?

> > There's a connection used by thread A for query X. At some random
> > point in the middle of a transaction, let's say thread A has fetched
> > the first 20 out of perhaps 123 records, the OS passes control to
> > thread B. Well, thread B also has a reference to the connection but
> > is totally unaware of the work performed on that connection by
> > thread A.

> 1. Why would you assume that the threads don't know what the other
> threads are doing? It's quite possible to sommunicate that info
> between threads.

I think it would be very difficult and error-prone.

Why not just use a new connection for each thread?

> 2. Thread B would call prepare on a statement, not a connection,
> right?

Well, prepare() has two aspects to it: (1) make the SQL safe for
execution (quoting), and (2) compiling the statement. I think that
whenever (2) is involved, the connection is involved, too. And at
least in JDBC and Perl DBI, prepare() and prepareStatement() are
called on the connection.

But yes, you're right: it doesn't have to involve the connection.

> So, thread B might very well use the same connection to start a
> transaction, while thread A has its transaction active, and the
> prepare a new statement under that new transaction. Or am I missing
> something?

No, you're right. I picked a bad example. You can certainly call
prepare() when in the middle of, say, fetching data.

However, this is not without problems in general. If you aren't done
fetching results from a query and someone else gets your connection to
use it for their own purpose, this closes the first result set. If then
control goes back to your first thread and you attempt to continue
reading data, you'll receive an exception from JayBird (JDBC):

org.firebirdsql.jdbc.FBSQLException: The result set is closed

But I don't know all the drivers and interfaces, and they do not all
behave the same way.

> I think you didn't answer the OP's question. Sorry. No offense.

None taken. :-)

> I just hope someone else will try to explain this a bit better.

That's what I hope, too.

--
Michael Ludwig