ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Young, Alistair" <alistair.yo...@logica.com>
Subject RE: Statement Caching Question
Date Tue, 11 Nov 2008 15:02:34 GMT
Thanks for the suggestions.

We really want the whole operation to be an "all or nothing" affair - so
keeping it all inside one transaction makes things a lot simpler for us!

And the reason that I don't want to use JDBC for this is primarily to
keep the number of technologies being used by our developers down (to
1!).

Having carried out some experimentation, it seems like my best bet is to
activate Oracle's statement caching.  We're already using iBATIS with a
custom Datasource, so inside that we can simple add:

	OracleConnection oconn = ...;

	oconn.setImplicitCachingEnabled(true);
	oconn.setStatementCacheSize(CACHE_SIZE);

The performance of Oracle caching vs. iBATIS caching appears to be
almost identical.  With the exception that, if I use the Oracle caching,
I don't suffer the "maximum cursors" problem.

Cheers for the pointers.


Alistair.

-----Original Message-----
From: Larry Meadors [mailto:larry.meadors@gmail.com] 
Sent: 11 November 2008 13:30
To: user-java@ibatis.apache.org
Subject: Re: Statement Caching Question

If you commit every few hundred rows, it will probably work for you...

>From a more practical perspective: If you are constructing all of the
sql in java already, what's the point of using ibatis here? Why not just
use straight JDBC for this one process? If you use the template approach
that Spring does for JDBC, it's pretty simple code.

Larry


On Tue, Nov 11, 2008 at 3:44 AM, Young, Alistair
<alistair.young@logica.com> wrote:
> We have a big loop in which we're using iBATIS to insert many rows 
> into a number of database tables.  Unfortunately, for various 
> pragmatic reasons, the underlying SQL map is using the $ notation for 
> substitution.  So it's something fairly unpleasant like:
>
> INSERT INTO $table$ ($columns$) VALUES ($values$)
>
> Of course, this means that each insert is considered a unique 
> statement and, with statement caching enabled, we eventually get an 
> error from our database:
>
> ORA-1000 maximum open cursors exceeded
>
> If we disable statement caching (in our SqlMapConfig file), then the 
> problem goes away - but 99.9% of the time we're running "proper" 
> queries and this seems like a sledgehammer to crack a nut.
>
> Is it possible to disable statement caching temporarily?  Or can 
> somebody suggest another solution?
>
> Thanks,
>
>
> Alistair.
> This e-mail and any attachment is for authorised use by the intended
> recipient(s) only. It may contain proprietary material, confidential 
> information and/or be subject to legal privilege. It should not be 
> copied, disclosed to, retained or used by, any other party. If you are

> not an intended recipient then please promptly delete this e-mail and 
> any attachment and all copies and inform the sender. Thank you.


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.



Mime
View raw message