javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream

[Deven You]

Hi Alan,

The Java Spec does not mention the thread safe for JDBC API. But I see 
the other code in SerialBlob/SerialClob have not consider it.

I think use buff == null to replace isFree is a good idea because it 
also avoid the problem for the condition buf == null && isFree == false 
so we won't need create a readObject method.

Thanks for your suggestion for isFree, I will correct it later.

Lance: How about your suggestion? Since you mentioned you will develop 
the implementation yourself. I use my implementation mainly for the test 
cases. But you may also take a look my implementation.

Thanks a lot!

On 09/21/2012 04:37 PM, Alan Bateman wrote:
> On 21/09/2012 04:21, Deven You wrote:
>> Hi Lance,
>>
>> I am very busy with other work so I can't work with the 
>> SerialBlob/SerialClob item for long time. I am very happy to refine 
>> the current test case and create new tests for SerialClob.
>>
>> I have create a new webre[1] for this task, please review it.
>>
>> [1] http://cr.openjdk.java.net/~youdwei/OJDK-576/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Eyoudwei/OJDK-576/webrev.01/>
>>
>> PS: If the isFree is not transient, I want to know how we add this 
>> field to the javadoc serialized form?
> I don't know very much about the rowset API and I can't see anything 
> to specify whether it is meant to be safe for use by concurrent 
> threads. There are clearly lots of issues here and implementing free 
> introduces a lot more, especially with the possibility of an 
> asynchronous free or more than one thread calling free at around the 
> same time.
>
> Have you considered "buf == null" to mean that the resources are 
> freed? That might avoid needing to change the serialized form. Also as 
> these types are serializable it means you have to consider the case 
> where you deserialize to buf == null && isFree == false for example. 
> On that point, it looks to me that this code needs a readObject anyway 
> (for several reasons).
>
> A small point is that "isFree" is a odd name for a method that doesn't 
> return a boolean. If the patch goes ahead then I think it needs a 
> better name, ensureNotFree or requireNotFree or something like that.
>
> -Alan.
>