iBATIS is calling different JDBC APIs for the different
statements. When you have it configured as a procedure, iBATIS is
calling JDBC's prepareCall API. Otherwise, iBATIS is calling JDBC's
prepareStatement API. This is why you're seeing different results from
the different configurations.
I still believe that the <procedure> problem lies in the
MySQL driver. If you're adventurous, try this raw JDBC code to see if
you still get the error (this is essentially what iBATIS is doing with
the <statement> configuration):
Connection connection = ... (get the connection from Driver
manager)
CallableStatement cs = connection.prepareCall ("{CALL deleteDatasetByResearcherIdAndId(?,?)}");
cs.setBigDecimal(1, new BigDecimal("1"));
cs.setBigDecimal(2, new BigDecimal("1"));
cs.execute();
Also look at these very recent MySQL bugs for similar issues
(not related to iBATIS):
Jeff Butler
On 11/22/06, Peter Andrews <[EMAIL PROTECTED]>
wrote:
I think the null pointer
exception is related to iBATIS because if I wrap the identical call in
a delete element rather than a procedure element, the procedure is
called and works just fine.
This works:
<delete id="deleteDatasetByResearcherIdAndId"
parameterClass="Map">
{CALL deleteDatasetByResearcherIdAndId(#pResearcherId:NUMERIC#,
#pDatasetId:NUMERIC#)}
</delete>
This throws null pointer exception:
<procedure id="deleteDatasetByResearcherIdAndIdProcedure"
resultClass="Integer" parameterClass="Map">
{CALL deleteDatasetByResearcherIdAndId(#pResearcherId:NUMERIC#,
#pDatasetId:NUMERIC# )}
</procedure>
This hangs:
<statement id="deleteDatasetByResearcherIdAndIdStatement"
resultClass="Integer" parameterClass="Map">
{CALL deleteDatasetByResearcherIdAndId(#pResearcherId:NUMERIC#,
#pDatasetId:NUMERIC#)}
</statement>
