Hello.
I think an efforts for readability of code came to improve stability of
code.
Please read next patch and give me your opinion.
Best regards.
Knut Anders Hatlen wrote:
TomohitoNakayama [EMAIL PROTECTED] writes:
Hello.
Knut Anders Hatlen (JIRA) wrote:
[...]
if
Hello.
Knut Anders Hatlen (JIRA) wrote:
However, compatibility with older servers seems to have been broken. When I try to stream
a lob (small enough to fit in the client's memory) to a 10.2.1.6 server, I get a protocol
error: java.sql.SQLException: A network protocol error was encountered
TomohitoNakayama [EMAIL PROTECTED] writes:
Hello.
Knut Anders Hatlen (JIRA) wrote:
[...]
if (stream == null) {
// same code as before for null
} else if (stream instanceof LayerBStreamedEXTDTAReaderInputStream) {
// new Layer B code
} else {
// same code as in the old
Thank you for your attention.
I think another patch is needed before committing ...
* BrokeredPreparedStatement now implements length-less setBinaryStream
and setCharacterStream. We could therefore remove them from
BrokeredPreparedStatement40.
* In DRDAConnThread.readAndSetExtParam(), some
Ooops.
* In NetStatementRequest, 0x8002 is used as a magic number many
places. Perhaps it could be explained in a comment, or a constant
could be used instead?
This number comes from specification of DRDA.
It told to set the Layer B 2-byte object length field to X'8004'.
I think comment is
TomohitoNakayama [EMAIL PROTECTED] writes:
Thank you for your attention.
I think another patch is needed before committing ...
Thank you for taking my comments into consideration.
* Blob/Clob: The variable willBeLayerBStreamed_ and the method
willBeLayerBStreamed() could be moved to the
Hello.
Thank you.
I think the problem was solved using EmbedPreparedStatement :)
Best regards.
Knut Anders Hatlen wrote:
TomohitoNakayama [EMAIL PROTECTED] writes:
Hello.
Reading the code ( BaseMonitor.java, modules.properties,
InternalDriver.java and so on ), it seems that possible
TomohitoNakayama [EMAIL PROTECTED] writes:
Hello.
Thank you for your comment :)
I think you understood what the issue is.
I understand your idea as using module of Engine where JDBC4.0 feature
is implemented
directly rather than via JDBC interface from NetworkServer.
I take the idea in
Hello.
Reading the code ( BaseMonitor.java, modules.properties,
InternalDriver.java and so on ),
it seems that possible class of engine is different between running
environment ...
Then, I think it is needed to consider when the class is not expected class.
Best regards.
Knut Anders
TomohitoNakayama [EMAIL PROTECTED] writes:
Hello.
Reading the code ( BaseMonitor.java, modules.properties,
InternalDriver.java and so on ), it seems that possible class of
engine is different between running environment ...
Yes, but the implementation of
TomohitoNakayama wrote:
Hello.
Thank you for your kindness :)
What is needed is calling method which was introduced in JDBC 4.0
from NetworkServer to utilize JDBC 4.0 feature in Engine.
Concretely,the method is PreparedStatement#setBinaryStream(int,
java.io.InputStream).
Hello.
Thank you for your comment :)
I think you understood what the issue is.
I understand your idea as using module of Engine where JDBC4.0 feature
is implemented
directly rather than via JDBC interface from NetworkServer.
I take the idea in consideration.
Best regards.
Oystein Grovlen
Tomohito Nakayama (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1471?page=comments#action_12448487 ]
Tomohito Nakayama commented on DERBY-1471:
--
I found that it is needed to make server side implementation
compatible with
Hello.
Thank you for your kindness :)
What is needed is calling method which was introduced in JDBC 4.0
from NetworkServer to utilize JDBC 4.0 feature in Engine.
Concretely,the method is PreparedStatement#setBinaryStream(int,
java.io.InputStream).
Hello.
IMHO, I think java.lang.IndexOutOfBoundsException is better than
java.lang.OutOfMemoryError for this situation ...
Error is too much for ...
Best regards.
Kristian Waagan wrote:
John Embretsen wrote:
Bryan Pendleton wrote:
Kristian Waagan commented on DERBY-1471:
TomohitoNakayama wrote:
Hello.
IMHO, I think java.lang.IndexOutOfBoundsException is better than
java.lang.OutOfMemoryError for this situation ...
Error is too much for ...
Hi Tomohito,
Not sure I understand what you are referring to in your comment. I'll
describe the situation I think you
Hello Kristian.
The OutOfMemoryError I have been talking about when reading LOBs with
unknown length on the client side, is an exception thrown by the JVM
when the LOB data cannot fit into the heap space. I did not plan to
throw this error myself.
Oh, I mistaken your thought.
I thought that
Bryan Pendleton wrote:
Kristian Waagan commented on DERBY-1471:
The approach is to exhaust the application stream and copy it into
memory to determine the length. If the data is too big to fit in memory,
the client will fail with an
John Embretsen wrote:
Bryan Pendleton wrote:
Kristian Waagan commented on DERBY-1471:
The approach is to exhaust the application stream and copy it into
memory to determine the length. If the data is too big to fit in
memory,
the client
Hello.
Concerning about use of memory at driver,
I briefly surveyed client driver program to find where *whole of* object
was expanded into memory before sending it,
from code searched with keyword writeScalarStream as starting point of
survey.
The result was as next.
When
Hello.
I think this should be told in DERBY-1472 more than DERBY-1471 ..
Best regards.
TomohitoNakayama wrote:
Hello.
Concerning about use of memory at driver,
I briefly surveyed client driver program to find where *whole of*
object was expanded into memory before sending it,
from code
Kristian Waagan commented on DERBY-1471:
The approach is to exhaust the application stream and copy it into
memory to determine the length. If the data is too big to fit in memory,
the client will fail with an out-of-memory exception.
That seems
22 matches
Mail list logo
