You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by François Schiettecatte <fs...@gmail.com> on 2010/03/12 21:54:14 UTC
iBatis 2.x vs. iBatis 3.x performance
Hi
Just wanted to share some impression on iBatis 2.x vs. iBatis 3.x performance.
Creating SqlSession appears to be very expensive vs. creating sqlMapClient. My application creates a SqlMapClient for each statement I run (inefficient I know, but I am accessing lots of tables spread across lots of databases, creating them when I need them saves me from having to manage lots of instances of SqlMapClient, across threads, etc...)
To test if I could speed things up I put in some code to store SqlSession() in a hash table (keyed by host/database/user/password/thread ID so that sqlSessions are not shared across threads) and performance is a lot better. In fact if a thread only runs selects, things are faster by a factor of 3 (nice !) On the other hand once inserts/updates/deletes occur, things are slower by a factor of 1.5 (which I can live with).
I did run into some issues with connection pooling. Creating a SqlSession() checks out a connection from the pool (I presume) and from what I can tell it does not check it back in until you close the session, so there is room for connections to timeout if I save them in a hash. With C3P0 I would get a "CommunicationsException: Communications link failure" when I used a connection which had timed out. On the other hand the built-in POOLED data source did not have this issue. I was not able to reliably get around this issue in C3P0 either by extending the timeout at the server end, or by setting up a ping query. Maybe one way to deal with this would be to check-out a connection from the pool at the start of a transaction and check it back in at the end of the transaction.
Cheers
François
--
François Schiettecatte
35 Washington Square North, #2
Salem, MA, 01970
617-909-2504
http://fschiettecatte.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: iBatis 2.x vs. iBatis 3.x performance
Posted by Clinton Begin <cl...@gmail.com>.
It's already separate. If you look at the code, you can create a
Configuration and pass it directly to the builder.
Clinton
2010/3/18 François Schiettecatte <fs...@gmail.com>
> Clinton
>
> Thanks for all the information, I reworked my code and am now keeping
> SqlSessionFactory(ies) around in a hash to create sessions from them as I
> need them. I will check into the named environments as you suggest.
> Meanwhile a suggestion would be to have a way to pre-parse the iBatis
> configuration and allowing one to apply a set of properties on demand, so
> splitting the reader step and properties step in this process:
>
> sqlSessionFactoryBuilder.build(reader, properties);
>
> make sense? Not sure how feasible or desirable this is given that I can
> keep SqlSessionFactory(ies) resident.
>
> Thanks again
>
> François
>
> On Mar 18, 2010, at 6:37 PM, Clinton Begin wrote:
>
> > You can also use named environments to manage different databases. And
> yes, you'd need a single SqlSessionFactory for each -- but I wouldn't create
> them on demand. I'd instantiate them and keep them resident.
> >
> > Clinton
> >
> > 2010/3/18 François Schiettecatte <fs...@gmail.com>
> > Clinton
> >
> > Thanks for the information, and indeed my code creating the
> SqlSessionFactoryBuilder() and the SqlSessionFactory() is wrong, which I
> will fix.
> >
> > However there is an interesting issue around SqlSessionFactory() though,
> when you take into account page 5, SqlSessionFactory() is geared toward
> setting up a factory around a single host name/database name/user name so
> does not work so well if you have multiple databases on multiple hosts.
> Unless there is a way to set configuration XML file property values when I
> create a new session, you have to use SqlSessionFactory().build(reader,
> properties) for each host name/database name/user name you access. Or did I
> miss something here ?
> >
> > Cheers
> >
> > François
> >
> >
> > On Mar 17, 2010, at 11:21 PM, Clinton Begin wrote:
> >
> > > I'm not sure what to say... this is not really an iBATIS issue.
> > >
> > > * First, you're purposefully going directly against a key part of the
> SqlSession contract. There's an entire section in the user guide about
> SqlSession lifecycle (Page 9) and you're completely ignoring it. This makes
> it very difficult to help you.
> > >
> > > * Keeping sessions (and therefore connections) open for long
> durations is a very bad practice. iBATIS won't do anything to help you
> there. We wrap connections with SqlSessions, thus to abuse one is to abuse
> the other.
> > >
> > > So I'm not sure there is any help for your situation.
> > >
> > > The most curious thing about your claim is that creating an iBATIS 3
> SqlSession is more expensive than creating an iBATIS 2 SqlMapClient. I find
> that very hard to believe.
> > >
> > > The creation of the SqlSession is almost nothing. It's a few class
> instantiations (almost free in modern JVMs), some getter/setter calls, some
> field assignments. There is one array and one hashmap created (maybe a
> little cost there, but not much). The most expensive line in the creation
> of a SqlSession is this one:
> > >
> > > Connection connection = dataSource.getConnection();
> > >
> > > This is entirely the cost incurred by your choice of DataSource.
> > >
> > > Compare that to the iBATIS 2 SqlMapClient, which had to parse XML,
> instantiate various maps, parse inline parameter maps and do tons of string
> manipulation. I just can't believe that your claim holds true. I'd love to
> see some numbers on that one, and a testing approach. Regardless, both
> creating multiple SqlMapClients and sharing SqlSessions are bad ideas, so
> the exercise would be strictly academic.
> > >
> > > So in a nutshell, I'm really not sure what I can do for you other than
> say: Best of luck.
> > >
> > > You're going far beyond the intended use of iBATIS and breaking clearly
> documented rules.
> > >
> > > Sorry.
> > >
> > > Clinton
> > >
> > >
> > >
> > >
> > >
> > > 2010/3/17 François Schiettecatte <fs...@gmail.com>
> > > Hi
> > >
> > > I have not heard back from anyone on this issue (which I am running
> into), is it a bug or a non-issue?
> > >
> > > I went back and retested it and I get the "CommunicationsException"
> with the POOLED data source as well (so my original testing was not up to
> par).
> > >
> > > For me this will require some amount of rework if I want to minimize
> the performance penalty I wrote about.
> > >
> > > Cheers
> > >
> > > François
> > >
> > >
> > > On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
> > >
> > > > I did run into some issues with connection pooling. Creating a
> SqlSession() checks out a connection from the pool (I presume) and from what
> I can tell it does not check it back in until you close the session, so
> there is room for connections to timeout if I save them in a hash. With C3P0
> I would get a "CommunicationsException: Communications link failure" when I
> used a connection which had timed out. On the other hand the built-in POOLED
> data source did not have this issue. I was not able to reliably get around
> this issue in C3P0 either by extending the timeout at the server end, or by
> setting up a ping query. Maybe one way to deal with this would be to
> check-out a connection from the pool at the start of a transaction and check
> it back in at the end of the transaction.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > > For additional commands, e-mail: user-java-help@ibatis.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > For additional commands, e-mail: user-java-help@ibatis.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: iBatis 2.x vs. iBatis 3.x performance
Posted by François Schiettecatte <fs...@gmail.com>.
Clinton
Thanks for all the information, I reworked my code and am now keeping SqlSessionFactory(ies) around in a hash to create sessions from them as I need them. I will check into the named environments as you suggest. Meanwhile a suggestion would be to have a way to pre-parse the iBatis configuration and allowing one to apply a set of properties on demand, so splitting the reader step and properties step in this process:
sqlSessionFactoryBuilder.build(reader, properties);
make sense? Not sure how feasible or desirable this is given that I can keep SqlSessionFactory(ies) resident.
Thanks again
François
On Mar 18, 2010, at 6:37 PM, Clinton Begin wrote:
> You can also use named environments to manage different databases. And yes, you'd need a single SqlSessionFactory for each -- but I wouldn't create them on demand. I'd instantiate them and keep them resident.
>
> Clinton
>
> 2010/3/18 François Schiettecatte <fs...@gmail.com>
> Clinton
>
> Thanks for the information, and indeed my code creating the SqlSessionFactoryBuilder() and the SqlSessionFactory() is wrong, which I will fix.
>
> However there is an interesting issue around SqlSessionFactory() though, when you take into account page 5, SqlSessionFactory() is geared toward setting up a factory around a single host name/database name/user name so does not work so well if you have multiple databases on multiple hosts. Unless there is a way to set configuration XML file property values when I create a new session, you have to use SqlSessionFactory().build(reader, properties) for each host name/database name/user name you access. Or did I miss something here ?
>
> Cheers
>
> François
>
>
> On Mar 17, 2010, at 11:21 PM, Clinton Begin wrote:
>
> > I'm not sure what to say... this is not really an iBATIS issue.
> >
> > * First, you're purposefully going directly against a key part of the SqlSession contract. There's an entire section in the user guide about SqlSession lifecycle (Page 9) and you're completely ignoring it. This makes it very difficult to help you.
> >
> > * Keeping sessions (and therefore connections) open for long durations is a very bad practice. iBATIS won't do anything to help you there. We wrap connections with SqlSessions, thus to abuse one is to abuse the other.
> >
> > So I'm not sure there is any help for your situation.
> >
> > The most curious thing about your claim is that creating an iBATIS 3 SqlSession is more expensive than creating an iBATIS 2 SqlMapClient. I find that very hard to believe.
> >
> > The creation of the SqlSession is almost nothing. It's a few class instantiations (almost free in modern JVMs), some getter/setter calls, some field assignments. There is one array and one hashmap created (maybe a little cost there, but not much). The most expensive line in the creation of a SqlSession is this one:
> >
> > Connection connection = dataSource.getConnection();
> >
> > This is entirely the cost incurred by your choice of DataSource.
> >
> > Compare that to the iBATIS 2 SqlMapClient, which had to parse XML, instantiate various maps, parse inline parameter maps and do tons of string manipulation. I just can't believe that your claim holds true. I'd love to see some numbers on that one, and a testing approach. Regardless, both creating multiple SqlMapClients and sharing SqlSessions are bad ideas, so the exercise would be strictly academic.
> >
> > So in a nutshell, I'm really not sure what I can do for you other than say: Best of luck.
> >
> > You're going far beyond the intended use of iBATIS and breaking clearly documented rules.
> >
> > Sorry.
> >
> > Clinton
> >
> >
> >
> >
> >
> > 2010/3/17 François Schiettecatte <fs...@gmail.com>
> > Hi
> >
> > I have not heard back from anyone on this issue (which I am running into), is it a bug or a non-issue?
> >
> > I went back and retested it and I get the "CommunicationsException" with the POOLED data source as well (so my original testing was not up to par).
> >
> > For me this will require some amount of rework if I want to minimize the performance penalty I wrote about.
> >
> > Cheers
> >
> > François
> >
> >
> > On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
> >
> > > I did run into some issues with connection pooling. Creating a SqlSession() checks out a connection from the pool (I presume) and from what I can tell it does not check it back in until you close the session, so there is room for connections to timeout if I save them in a hash. With C3P0 I would get a "CommunicationsException: Communications link failure" when I used a connection which had timed out. On the other hand the built-in POOLED data source did not have this issue. I was not able to reliably get around this issue in C3P0 either by extending the timeout at the server end, or by setting up a ping query. Maybe one way to deal with this would be to check-out a connection from the pool at the start of a transaction and check it back in at the end of the transaction.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > For additional commands, e-mail: user-java-help@ibatis.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: iBatis 2.x vs. iBatis 3.x performance
Posted by Clinton Begin <cl...@gmail.com>.
You can also use named environments to manage different databases. And yes,
you'd need a single SqlSessionFactory for each -- but I wouldn't create them
on demand. I'd instantiate them and keep them resident.
Clinton
2010/3/18 François Schiettecatte <fs...@gmail.com>
> Clinton
>
> Thanks for the information, and indeed my code creating the
> SqlSessionFactoryBuilder() and the SqlSessionFactory() is wrong, which I
> will fix.
>
> However there is an interesting issue around SqlSessionFactory() though,
> when you take into account page 5, SqlSessionFactory() is geared toward
> setting up a factory around a single host name/database name/user name so
> does not work so well if you have multiple databases on multiple hosts.
> Unless there is a way to set configuration XML file property values when I
> create a new session, you have to use SqlSessionFactory().build(reader,
> properties) for each host name/database name/user name you access. Or did I
> miss something here ?
>
> Cheers
>
> François
>
>
> On Mar 17, 2010, at 11:21 PM, Clinton Begin wrote:
>
> > I'm not sure what to say... this is not really an iBATIS issue.
> >
> > * First, you're purposefully going directly against a key part of the
> SqlSession contract. There's an entire section in the user guide about
> SqlSession lifecycle (Page 9) and you're completely ignoring it. This makes
> it very difficult to help you.
> >
> > * Keeping sessions (and therefore connections) open for long durations
> is a very bad practice. iBATIS won't do anything to help you there. We
> wrap connections with SqlSessions, thus to abuse one is to abuse the other.
> >
> > So I'm not sure there is any help for your situation.
> >
> > The most curious thing about your claim is that creating an iBATIS 3
> SqlSession is more expensive than creating an iBATIS 2 SqlMapClient. I find
> that very hard to believe.
> >
> > The creation of the SqlSession is almost nothing. It's a few class
> instantiations (almost free in modern JVMs), some getter/setter calls, some
> field assignments. There is one array and one hashmap created (maybe a
> little cost there, but not much). The most expensive line in the creation
> of a SqlSession is this one:
> >
> > Connection connection = dataSource.getConnection();
> >
> > This is entirely the cost incurred by your choice of DataSource.
> >
> > Compare that to the iBATIS 2 SqlMapClient, which had to parse XML,
> instantiate various maps, parse inline parameter maps and do tons of string
> manipulation. I just can't believe that your claim holds true. I'd love to
> see some numbers on that one, and a testing approach. Regardless, both
> creating multiple SqlMapClients and sharing SqlSessions are bad ideas, so
> the exercise would be strictly academic.
> >
> > So in a nutshell, I'm really not sure what I can do for you other than
> say: Best of luck.
> >
> > You're going far beyond the intended use of iBATIS and breaking clearly
> documented rules.
> >
> > Sorry.
> >
> > Clinton
> >
> >
> >
> >
> >
> > 2010/3/17 François Schiettecatte <fs...@gmail.com>
> > Hi
> >
> > I have not heard back from anyone on this issue (which I am running
> into), is it a bug or a non-issue?
> >
> > I went back and retested it and I get the "CommunicationsException" with
> the POOLED data source as well (so my original testing was not up to par).
> >
> > For me this will require some amount of rework if I want to minimize the
> performance penalty I wrote about.
> >
> > Cheers
> >
> > François
> >
> >
> > On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
> >
> > > I did run into some issues with connection pooling. Creating a
> SqlSession() checks out a connection from the pool (I presume) and from what
> I can tell it does not check it back in until you close the session, so
> there is room for connections to timeout if I save them in a hash. With C3P0
> I would get a "CommunicationsException: Communications link failure" when I
> used a connection which had timed out. On the other hand the built-in POOLED
> data source did not have this issue. I was not able to reliably get around
> this issue in C3P0 either by extending the timeout at the server end, or by
> setting up a ping query. Maybe one way to deal with this would be to
> check-out a connection from the pool at the start of a transaction and check
> it back in at the end of the transaction.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> > For additional commands, e-mail: user-java-help@ibatis.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: iBatis 2.x vs. iBatis 3.x performance
Posted by François Schiettecatte <fs...@gmail.com>.
Clinton
Thanks for the information, and indeed my code creating the SqlSessionFactoryBuilder() and the SqlSessionFactory() is wrong, which I will fix.
However there is an interesting issue around SqlSessionFactory() though, when you take into account page 5, SqlSessionFactory() is geared toward setting up a factory around a single host name/database name/user name so does not work so well if you have multiple databases on multiple hosts. Unless there is a way to set configuration XML file property values when I create a new session, you have to use SqlSessionFactory().build(reader, properties) for each host name/database name/user name you access. Or did I miss something here ?
Cheers
François
On Mar 17, 2010, at 11:21 PM, Clinton Begin wrote:
> I'm not sure what to say... this is not really an iBATIS issue.
>
> * First, you're purposefully going directly against a key part of the SqlSession contract. There's an entire section in the user guide about SqlSession lifecycle (Page 9) and you're completely ignoring it. This makes it very difficult to help you.
>
> * Keeping sessions (and therefore connections) open for long durations is a very bad practice. iBATIS won't do anything to help you there. We wrap connections with SqlSessions, thus to abuse one is to abuse the other.
>
> So I'm not sure there is any help for your situation.
>
> The most curious thing about your claim is that creating an iBATIS 3 SqlSession is more expensive than creating an iBATIS 2 SqlMapClient. I find that very hard to believe.
>
> The creation of the SqlSession is almost nothing. It's a few class instantiations (almost free in modern JVMs), some getter/setter calls, some field assignments. There is one array and one hashmap created (maybe a little cost there, but not much). The most expensive line in the creation of a SqlSession is this one:
>
> Connection connection = dataSource.getConnection();
>
> This is entirely the cost incurred by your choice of DataSource.
>
> Compare that to the iBATIS 2 SqlMapClient, which had to parse XML, instantiate various maps, parse inline parameter maps and do tons of string manipulation. I just can't believe that your claim holds true. I'd love to see some numbers on that one, and a testing approach. Regardless, both creating multiple SqlMapClients and sharing SqlSessions are bad ideas, so the exercise would be strictly academic.
>
> So in a nutshell, I'm really not sure what I can do for you other than say: Best of luck.
>
> You're going far beyond the intended use of iBATIS and breaking clearly documented rules.
>
> Sorry.
>
> Clinton
>
>
>
>
>
> 2010/3/17 François Schiettecatte <fs...@gmail.com>
> Hi
>
> I have not heard back from anyone on this issue (which I am running into), is it a bug or a non-issue?
>
> I went back and retested it and I get the "CommunicationsException" with the POOLED data source as well (so my original testing was not up to par).
>
> For me this will require some amount of rework if I want to minimize the performance penalty I wrote about.
>
> Cheers
>
> François
>
>
> On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
>
> > I did run into some issues with connection pooling. Creating a SqlSession() checks out a connection from the pool (I presume) and from what I can tell it does not check it back in until you close the session, so there is room for connections to timeout if I save them in a hash. With C3P0 I would get a "CommunicationsException: Communications link failure" when I used a connection which had timed out. On the other hand the built-in POOLED data source did not have this issue. I was not able to reliably get around this issue in C3P0 either by extending the timeout at the server end, or by setting up a ping query. Maybe one way to deal with this would be to check-out a connection from the pool at the start of a transaction and check it back in at the end of the transaction.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: iBatis 2.x vs. iBatis 3.x performance
Posted by Clinton Begin <cl...@gmail.com>.
I'm not sure what to say... this is not really an iBATIS issue.
* First, you're purposefully going directly against a key part of the
SqlSession contract. There's an entire section in the user guide about
SqlSession lifecycle (Page 9) and you're completely ignoring it. This makes
it very difficult to help you.
* Keeping sessions (and therefore connections) open for long durations is
a very bad practice. iBATIS won't do anything to help you there. We wrap
connections with SqlSessions, thus to abuse one is to abuse the other.
So I'm not sure there is any help for your situation.
The most curious thing about your claim is that creating an iBATIS 3
SqlSession is more expensive than creating an iBATIS 2 SqlMapClient. I find
that very hard to believe.
The creation of the SqlSession is almost nothing. It's a few class
instantiations (almost free in modern JVMs), some getter/setter calls, some
field assignments. There is one array and one hashmap created (maybe a
little cost there, but not much). The most expensive line in the creation
of a SqlSession is this one:
Connection connection = dataSource.getConnection();
This is entirely the cost incurred by your choice of DataSource.
Compare that to the iBATIS 2 SqlMapClient, which had to parse XML,
instantiate various maps, parse inline parameter maps and do tons of string
manipulation. I just can't believe that your claim holds true. I'd love to
see some numbers on that one, and a testing approach. Regardless, both
creating multiple SqlMapClients and sharing SqlSessions are bad ideas, so
the exercise would be strictly academic.
So in a nutshell, I'm really not sure what I can do for you other than say:
Best of luck.
You're going far beyond the intended use of iBATIS and breaking clearly
documented rules.
Sorry.
Clinton
2010/3/17 François Schiettecatte <fs...@gmail.com>
> Hi
>
> I have not heard back from anyone on this issue (which I am running into),
> is it a bug or a non-issue?
>
> I went back and retested it and I get the "CommunicationsException" with
> the POOLED data source as well (so my original testing was not up to par).
>
> For me this will require some amount of rework if I want to minimize the
> performance penalty I wrote about.
>
> Cheers
>
> François
>
>
> On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
>
> > I did run into some issues with connection pooling. Creating a
> SqlSession() checks out a connection from the pool (I presume) and from what
> I can tell it does not check it back in until you close the session, so
> there is room for connections to timeout if I save them in a hash. With C3P0
> I would get a "CommunicationsException: Communications link failure" when I
> used a connection which had timed out. On the other hand the built-in POOLED
> data source did not have this issue. I was not able to reliably get around
> this issue in C3P0 either by extending the timeout at the server end, or by
> setting up a ping query. Maybe one way to deal with this would be to
> check-out a connection from the pool at the start of a transaction and check
> it back in at the end of the transaction.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
Re: iBatis 2.x vs. iBatis 3.x performance
Posted by François Schiettecatte <fs...@gmail.com>.
Hi
I have not heard back from anyone on this issue (which I am running into), is it a bug or a non-issue?
I went back and retested it and I get the "CommunicationsException" with the POOLED data source as well (so my original testing was not up to par).
For me this will require some amount of rework if I want to minimize the performance penalty I wrote about.
Cheers
François
On Mar 12, 2010, at 3:54 PM, François Schiettecatte wrote:
> I did run into some issues with connection pooling. Creating a SqlSession() checks out a connection from the pool (I presume) and from what I can tell it does not check it back in until you close the session, so there is room for connections to timeout if I save them in a hash. With C3P0 I would get a "CommunicationsException: Communications link failure" when I used a connection which had timed out. On the other hand the built-in POOLED data source did not have this issue. I was not able to reliably get around this issue in C3P0 either by extending the timeout at the server end, or by setting up a ping query. Maybe one way to deal with this would be to check-out a connection from the pool at the start of a transaction and check it back in at the end of the transaction.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org