It's dark here.

What do you mean by that?  You need to use synchronize one way or
another if you want to share a resource thread safe (leaving out
volatile etc.).  And the performance penalty is negligible - unless you
hold the lock for the complete course of action.

All Vector methods are synchronized.  I don't see how that should create
a problem.  But then again it is not very clear from what you write what
you want to do.  Is your Vector some form of connection pool?  If so,
there are plenty implementations out there - even free ones.  And they
have all the whistles and bells...

You cannot use a JDBC connection from multiple threads /at the same time/.

Regards

    robert

nullstring wrote On 11/21/06 11:06,:

   Then make sure the "variable count" is always equal to one.

   The methods of java.util.Vector are synchronized, so no
individual method call will get into thread trouble.  However,
sequences of method calls can still produce "problems with
synchronizing."

   I'm not 100% sure what you're asking here, but I think the
answer is "Yes, you have problems with synchronizing."  (Reason:
your understanding of threads and synchronization is incomplete,
which means you've probably made mistakes.  You need to learn
more about threads to improve your chances of success.)

If by "performance" you mean "corrupt the data as rapidly as possible", by
all means, let her rip. You either need synchronization or you don't. You
need it if you have two or more threads attempting to access the same
resource. You don't need it if the threads accessing entirely different
resources. It isn't your choice.

I'll qualify that last statement: It might be your choice if you can think
of a way to arrange for the resource not to be shared, or in the extremely
rare and somewhat implementation-dependent case where you can guarantee that
access to shared data is intrinsically atomic.