Hello Gabriel,
>But as I understand it, this would only affect performance when LONG
>data is written, is that correct?
I'm more concerned about the effect on statements that do not need the
lock ('B' in your example), as 99.99% are 'B' cases ... they get and
release a lock for nothing in 99.99% of all cases and applications
(which because of being transaction oriented, use 1 thread per
connection).
>So if statement 'A' writes LONG data and statement 'B' is any other
>write operation (without LONG data), I think the following can happen:
>
> Thread 1: Thread 2:
>A.executeUpdate (start)*
> ...
> ... B.executeUpdate();
> ....
>A.executeUpdate (end)*
>Is my understanding correct? Do you always synchronize on the
>Connection-Object?
We synchronize the physical request/reply operation on a connection.
One statement may require > 1 of these communications (long data, executeBatch,
some error conditions).
>As the driver releases the LOCK on the Connection-Object between
>start/end, other Threads can execute statements using the same
>connection that will not affect statement A, as long as not the same
>database-table is concerned [or perhaps the same row of this table is
>concerned].
>But if B.executeUpdate() writes to the same table [same row of that
>table], this could lead to the posted problem.
>If so, there would perhaps be a more efficient way to synchronize so
>that Thread-2 can still execute Updates as long as we know that this can
>not cause any problem with the statement A.executeUpdate (in the example
>above).
The problem is that B is not able to know what is harmful currently and
what's not. You can only wait until no harm can be done because you
get the 'connection lock'. The client cannot estimate what the statement
will do on the database.
Regards
Alexander Schröder
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
