Hello Alexander
I was able to fix our dead-lock problem so that we can now successfully
use the proposed workaround ...
synchronized(statement.getConnection()) {
statement.execute();
}
... for writing LONG data. It seems that for our application that
problem is solved. Thank you!
If you intend to do this ...
> The only workaround in the driver would be to synchronize the full
execution of
> the statement, and not only synchronize the single request/reply
operation.
> We *may* do this, but we have to check the performance implications ...
... it could perhaps be useful to allow the user to switch this option
on or off by setting a property to the driver.
The implementation could then perhaps be that way for Statement.execute().
execute() {
if (threadSaveLongWriteOptionOn) synchronized(con) {executeImpl(); }
else executeImpl();
}
executeImpl() {
...
}
Well, perhaps it is more complicated and inpractical. We'll see what
you'll decide.
Best regards,
Gabriel Matter
Invoca Systems
Schroeder, Alexander wrote:
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]
