ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: iBatis-362 - Caching broken for stored procs
Date Mon, 28 Apr 2008 00:54:57 GMT
I'm not implying anything.  I was having a little fun with Jason, who said:
"I'm a little confused about the difference between regular results and OUT
results. I assume the return result of a stored function is always an OUT
parameter."

Clinton

On Sun, Apr 27, 2008 at 10:29 AM, Mississippi John Hurt <johnhurt@gmail.com>
wrote:

> Are you implying that Oracle stored procs can only return output via the
> OUT parameters, and cannot return resultsets like a return value for a
> function?
>
>
> On Tue, Apr 22, 2008 at 3:01 PM, Clinton Begin <clinton.begin@gmail.com>
> wrote:
>
> >
> > You must be an Oracle user... :-)
> >
> > CallableStatements can return ResultSets just like any PreparedStatement
> > can.  The difference is that CallableStatements can also have results of
> > their own, which is the more traditional "output parameter" from the JDBC
> > API perspective.  It is these results that are not currently cached by
> > iBATIS.
> >
> > http://java.sun.com/j2se/1.4.2/docs/api/java/sql/CallableStatement.html
> >
> > In practice the difference is:
> >
> > ResultSet rs = cs.executeQuery(...); // would be cached.
> > vs.
> > cs.getObject(...); // would NOT be cached, even if it's a ResultSet
> > mapped to a ref cursor returned from an Oracle proc.
> >
> > Cheers,
> > Clinton
> >
> >
> >
> > On Tue, Apr 22, 2008 at 3:47 PM, Jason Bennett <
> > Jason.Bennett@3nonline.com> wrote:
> >
> > >  Thanks for the response, Clint.
> > >
> > >
> > >
> > > I'm a little confused about the difference between regular results and
> > > OUT results. I assume the return result of a stored function is always an
> > > OUT parameter.
> > >
> > >
> > >
> > > My current fix is to use LRUMap from commons-collections, but what I'd
> > > really like is manual access to the iBatis cache, so that I can use the
> > > flush interval and other features. Could a fix for this be to expose the
> > > cache through the sqlmap interface?
> > >
> > >
> > >
> > >                                     jason
> > >
> > >
> > >  ------------------------------
> > >
> > > *From:* Clinton Begin [mailto:clinton.begin@gmail.com]
> > > *Sent:* Tuesday, April 22, 2008 2:10 PM
> > > *To:* user-java@ibatis.apache.org
> > > *Subject:* Re: iBatis-362 - Caching broken for stored procs
> > >
> > >
> > >
> > > The bug is actually invalid.  The reason it "worked" in 2.1.5 is that
> > > procs weren't cached at all.  In 2.2.0+ proc statements were cached, but
> > > there's no way to cache output parameters, as you're passing the object in
> > > (so we can't cache it).  We could build something in to mock the parameter
> > > object and hold the out params, but that's nontrivial.  So for now, no,
> > > there is no way to cache output parameters.  You can cache regular results
> > > from a proc of course, just not the OUT params...
> > >
> > > Clinton
> > >
> > > On Thu, Apr 17, 2008 at 1:32 PM, Jason Bennett <
> > > Jason.Bennett@3nonline.com> wrote:
> > >
> > > I ran across this bug today, and was surprised that there hasn't been
> > > any discussion. As far as I can tell, iBatis caching does not work for
> > > stored procedure return values – you always get a null (or empty)
> > > value out of the cache.
> > >
> > > Has anyone else experienced this (or not), and found a workaround?
> > >
> > >                         jason
> > >
> > >
> > >
> >
> >
>

Mime
View raw message