Re: [-3102]: Invalid subtrans structure / update / column of type LONG / JDBC

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]