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: SqlMapClient factory and threadlocal?
Date Thu, 26 Oct 2006 23:40:23 GMT
iBATIS doesn't try to solve this problem (well, the DAO framework used to,
but that was just deprecated).

I strongly suggest you look at Spring before writing your own.

Cheers,
Clinton


On 10/26/06, lodsmor02@sneakemail.com <lodsmor02@sneakemail.com> wrote:
>
> One more question, in a servlet environment where threads are reused to
> serve requests, am I obliged to demarcate transactions (so that connections
> are acquired and released properly) or are there any sort of provisions in
> iBATIS to solve this problem? I'm wondering if I'd need to build a front
> controller or filter to handle that; if using a filter to wrap servlets, the
> code would be something like:
>
> SqlMapClient sqlMap = SqlMapSingleton.getInstance();
>
> try {
>    sqlMap.startTransaction();
>    chain.doFilter(request, response);
>    sqlMap.commitTransaction ();
> } catch (Exception e) {
>    throw new RuntimeException(e);
> } finally {
>    try { sqlMap.endTransaction(); } catch (SQLException e) { log.error("error
> ending transaction: " + e.getMessage()); }
> }
>
> Is this really needed?
>
> On 10/26/06, Larry Meadors lmeadors-at-apache.org |ibatis| < ...> wrote:
> >
> > Yes.
> >
> > Larry
> >
> >
> > On 10/26/06, lodsmor02@sneakemail.com <lodsmor02@sneakemail.com> wrote:
> > > Maybe I haven't understood the architecture then. What will happen
> > when I
> > > perform
> > > startTransaction()/commitTransaction()/endTransaction() or
> > > getCurrentConnection() in a SqlMapClient object, what's happening? Is
> > iBATIS
> > > holding ThreadLocal instances itself to make things work in a
> > multi-threaded
> > > application?
> > >
> > >
> > > On 10/26/06, Larry Meadors lmeadors-at-apache.org |ibatis| < ...>
> > wrote:
> > > > You can keep it as a singleton, using either spring or a static
> > > > variable somewhere.
> > > >
> > > > There is no need to keep it in a threadlocal variable.
> > > >
> > > > Larry
> > > >
> > > >
> > > > On 26 Oct 2006 19:34:28 -0000, lodsmor02@sneakemail.com
> > > > < lodsmor02@sneakemail.com> wrote:
> > > > >
> > > > > Is there a way to avoid reparsing the configuration file every
> > time a
> > > SqlMapClient object is needed? From my understanding, a construct such
> > as:
> > > > >
> > > > > Reader reader = Resources.getResourceAsReader("sqlMap-config.xml
> > ");
> > > > > SqlMapClient sqlMap =
> > > SqlMapClientBuilder.buildSqlMapClient(reader);
> > > > >
> > > > > is needed to create a SqlMapClient, but this requires a full
> > parsing of
> > > the XML configuration file (taking 10-30ms to process). I wonder why
> > there's
> > > no way to cache a builder object capable of producing SqlMapClient
> > objects
> > > from a pre-parsed XML configuration file.
> > > > >
> > > > > Additionaly, are there any provisions to store a SqlMapClient in
a
> > > ThreadLocal object, or I must implement that?
> > > > >
> > > > > Cheers
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
View raw message