InstantDB Project
About InstantDB
Project Mail Lists
Short History
Reporting Bugs
Screen Shots
3rd Party Examples
FAQs

Software
Downloads
Documentation
CVS Repositories
Roadmap
License

About Enhydra.org
Who We Are
News, Articles & Events
Getting Involved
Contact Us

Community
Demos
Contributions
Resources
Case Studies
On The Edge! -NEW-
Commercial Vendors

There's a difference between "multithread-safe" and using something across
multiple threads in a way that makes sense. While it may be "safe" to use
the same connection on different threads, it doesn't make sense to use a
connection that way in an uncontrolled manner.

A database connection represents a set of resources currently "active"
between a db client and server. For example, if you've executed a query, the
connection is the ultimate "owner" of the result set (even though you've
used a statement object, you've gotten that from the connection). You can't
execute another query (in any thread) on the connection without closing the
statement or losing the result set.

So if you want to use an open, active (i.e. one that's got a result set in
use or some such) across threads, it had better be done in a synchronized
way. For example:

- thread 1 executes the query
- thread 2 blocks until getting notification that the query has completed in
thread 1
- thread 2 then retrieves the elements of the result set it wants
- thread 3 blocks until thread 2 signals it's done working on the result set
- thread 3 then retrieves the elements it needs
- thread 1 blocks until everyone's done using the active result set
- thread 1 executes next query and then start the cycle over

Logically speaking, if you could just open a connection and do anything with
it anywhere at any time, there would be no need for the connection pooling
aspects of the specification. Just use one and be done with it.

Donnie



-----Original Message-----
From: owner-instantDB@enhydra.org [mailto:owner-instantDB@enhydra.org]On
Behalf Of Scott Plante
Sent: Thursday, March 01, 2001 8:47 PM
To: instantDB@enhydra.org
Subject: Re: InstantDB: database shutting itself down without error


Hmmm, I stand corrected. That's what I get for not double-checking
before I post :-( I could have sworn I learned that somewhere.

So why would you want to share a connection between threads? Do you need
the threads to operate within the same transaction?

Scott

Peter Yuill wrote:

>> You should never have multiple threads accessing the same connection
>> unless you're using some pooling mechanism that insures that two threads
>> can't using a connection at the same time. This is true for any JDBC
>> connection, not just InstantDB.
>
>
> Not so according to the spec. Section 9.2 says:
> "We require that all operations on all the java.sql objects be
multi-thread safe and able to
> cope correctly with having several threads simultaneously calling the same
object"
>
> If multi-threading is the problem (only speculation at this point) then
its a bug.
>
> Regards,
> Peter Yuill
>
> --------------------------------------------------------------------------
---
> To unsubscribe from this mailing list, send email to majordomo@enhydra.org
> with the text "unsubscribe instantdb" in the body of the email.
> If you have other questions regarding this mailing list, send email to
> the list admin at owner-instantdb@enhydra.org.
>
>

----------------------------------------------------------------------------
-
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe instantdb" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-instantdb@enhydra.org.

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@enhydra.org
with the text "unsubscribe instantdb" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-instantdb@enhydra.org.