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 Guy Rouillier <gu...@burntmail.com> on 2009/09/23 00:10:40 UTC
IBatis 3 TypeHandler resolution
I'm new to iBatis and writing my first type handler to map a database
column to an enum whose underlying type is integer. I've got it working
after falling prey to some Java limitations (can't extend enum, can't
define static methods in interfaces, the combination of which seems to
prevent me from writing a generalized type handler for all integer-based
enums.)
However, I'm a little confused as to how type handlers get mapped. Here
is my entry in the iBatisConfig.xml file (shortened for readability):
<typeHandlers>
<typeHandler javaType="OrderStatusEnum" jdbcType="VARCHAR"
handler="OrderStatusEnumTypeHandler"/>
</typeHandlers>
Through trial and error, I discovered that in order to have iBatis apply
this type handler, in the resultMap result entry I had to specify both
javaType and jdbcType. If I supplied only javaType, then iBatis applied
the default enumTypeHandler (unsuccessfully).
I then found that if I supply typeHandler on the result entry in the
resultMap, I can dispense with the typeHandler declaration in
iBatisConfig, and also dispense with javaType and jdbcType in the result
entry. That's less typing and accomplishes the same thing.
Am I missing something? (Likely).
Thanks.
--
Guy Rouillier
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: IBatis 3 TypeHandler resolution
Posted by Guy Rouillier <gu...@burntmail.com>.
Clinton, thanks for the reply. I've completed the type handler
implementation. For me, the type handler is specific to one class,
which happens to be an enum. For better encapsulation, I made the type
handler a static class inside the enum class file. Everything works fine.
But that got me to thinking: in this particular case there is a
one-to-one correspondence between type handler and the class that it
handles, so automatically associating the handler to the class would be
a convenience to the programmer. At first I was thinking of some
introspection looking for a particular class name, but on second thought
an @TypeHandler annotation would probably be more general.
Have you already thought of something like this and decided the pain
wasn't worth the gain?
Clinton Begin wrote:
> No, that's actually correct. If you specify the JDBC type in the type
> handler, then you have to specify it in the result map. However, if you
> don't specify the JDBC type in either, that should work too, but will
> override ALL string types (for example).
>
> The reason is that iBATIS doesn't introspect the column type at runtime.
>
> Clinton
>
> On Tue, Sep 22, 2009 at 4:10 PM, Guy Rouillier <guyr-ml1@burntmail.com
> <ma...@burntmail.com>> wrote:
>
> I'm new to iBatis and writing my first type handler to map a
> database column to an enum whose underlying type is integer. I've
> got it working after falling prey to some Java limitations (can't
> extend enum, can't define static methods in interfaces, the
> combination of which seems to prevent me from writing a generalized
> type handler for all integer-based enums.)
>
> However, I'm a little confused as to how type handlers get mapped.
> Here is my entry in the iBatisConfig.xml file (shortened for
> readability):
>
> <typeHandlers>
> <typeHandler javaType="OrderStatusEnum" jdbcType="VARCHAR"
> handler="OrderStatusEnumTypeHandler"/>
> </typeHandlers>
>
> Through trial and error, I discovered that in order to have iBatis
> apply this type handler, in the resultMap result entry I had to
> specify both javaType and jdbcType. If I supplied only javaType,
> then iBatis applied the default enumTypeHandler (unsuccessfully).
>
> I then found that if I supply typeHandler on the result entry in the
> resultMap, I can dispense with the typeHandler declaration in
> iBatisConfig, and also dispense with javaType and jdbcType in the
> result entry. That's less typing and accomplishes the same thing.
>
> Am I missing something? (Likely).
>
> Thanks.
>
> --
> Guy Rouillier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> <ma...@ibatis.apache.org>
> For additional commands, e-mail: user-java-help@ibatis.apache.org
> <ma...@ibatis.apache.org>
>
>
--
Guy Rouillier
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org
Re: IBatis 3 TypeHandler resolution
Posted by Clinton Begin <cl...@gmail.com>.
No, that's actually correct. If you specify the JDBC type in the type
handler, then you have to specify it in the result map. However, if you
don't specify the JDBC type in either, that should work too, but will
override ALL string types (for example).
The reason is that iBATIS doesn't introspect the column type at runtime.
Clinton
On Tue, Sep 22, 2009 at 4:10 PM, Guy Rouillier <gu...@burntmail.com>wrote:
> I'm new to iBatis and writing my first type handler to map a database
> column to an enum whose underlying type is integer. I've got it working
> after falling prey to some Java limitations (can't extend enum, can't define
> static methods in interfaces, the combination of which seems to prevent me
> from writing a generalized type handler for all integer-based enums.)
>
> However, I'm a little confused as to how type handlers get mapped. Here is
> my entry in the iBatisConfig.xml file (shortened for readability):
>
> <typeHandlers>
> <typeHandler javaType="OrderStatusEnum" jdbcType="VARCHAR"
> handler="OrderStatusEnumTypeHandler"/>
> </typeHandlers>
>
> Through trial and error, I discovered that in order to have iBatis apply
> this type handler, in the resultMap result entry I had to specify both
> javaType and jdbcType. If I supplied only javaType, then iBatis applied the
> default enumTypeHandler (unsuccessfully).
>
> I then found that if I supply typeHandler on the result entry in the
> resultMap, I can dispense with the typeHandler declaration in iBatisConfig,
> and also dispense with javaType and jdbcType in the result entry. That's
> less typing and accomplishes the same thing.
>
> Am I missing something? (Likely).
>
> Thanks.
>
> --
> Guy Rouillier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
RE: SqlMapClient gets stuck when running under multiple threads
Posted by Ejaz X Mohammed <ej...@jpmorgan.com>.
Note! Transactions cannot be nested. Calling .startTransaction() from the same thread more than once,
before calling commit() or rollback(), will cause an exception to be thrown. In other words, each thread can
have -at most- one transaction open, per SqlMapClient instance.
Note! SqlMapClient transactions use Java's ThreadLocal store for storing transactional objects. This
means that each thread that calls startTransaction() will get a unique Connection object for their transaction.
The only way to return a connection to the DataSource (or close the connection) is to call
commitTransaction() or endTransaction(). Not doing so could cause your pool to run out of connections
and lock up
Thanks ... I see that SqlMapClient already uses ThreadLocal feature.
I've commented out my threadlocal stuff ... now testing it.
Regards
Ejaz
From: Clinton Begin [mailto:clinton.begin@gmail.com]
Sent: Tuesday, September 22, 2009 6:30 PM
To: user-java@ibatis.apache.org
Subject: Re: SqlMapClient gets stuck when running under multiple threads
SqlMapClient supports multiple threads, you should not have more than one copy. In fact, if you do, you might run into these kinds of problems.
I think that's in the documentation in the first sections regarding SqlMapClient.
Clinton
On Tue, Sep 22, 2009 at 4:22 PM, Ejaz X Mohammed <ej...@jpmorgan.com>> wrote:
Hello,
I'm having problem using SqlMapClient in multiple threads ...
I'm storing SqlMapClient instance as ThreadLocal variable - thus each thread gets it's own separate copy.
I've supplied startTransaction(), commitTransaction() and endTransaction() which operate on thread local SqlMapClient instance
When running the application under multiple threads, it seems to get stuck on update on same table...
Did anyone notice this earlier?
Any solutions ...?
Regards
Ejaz
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org<ma...@ibatis.apache.org>
For additional commands, e-mail: user-java-help@ibatis.apache.org<ma...@ibatis.apache.org>
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Re: SqlMapClient gets stuck when running under multiple threads
Posted by Clinton Begin <cl...@gmail.com>.
SqlMapClient supports multiple threads, you should not have more than one
copy. In fact, if you do, you might run into these kinds of problems.
I think that's in the documentation in the first sections regarding
SqlMapClient.
Clinton
On Tue, Sep 22, 2009 at 4:22 PM, Ejaz X Mohammed <ejaz.mohammed@jpmorgan.com
> wrote:
> Hello,
>
> I'm having problem using SqlMapClient in multiple threads ...
>
> I'm storing SqlMapClient instance as ThreadLocal variable - thus each
> thread gets it's own separate copy.
>
> I've supplied startTransaction(), commitTransaction() and endTransaction()
> which operate on thread local SqlMapClient instance
>
> When running the application under multiple threads, it seems to get stuck
> on update on same table...
>
> Did anyone notice this earlier?
>
> Any solutions ...?
>
> Regards
> Ejaz
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.com/pages/disclosures/email.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>
SqlMapClient gets stuck when running under multiple threads
Posted by Ejaz X Mohammed <ej...@jpmorgan.com>.
Hello,
I'm having problem using SqlMapClient in multiple threads ...
I'm storing SqlMapClient instance as ThreadLocal variable - thus each thread gets it's own separate copy.
I've supplied startTransaction(), commitTransaction() and endTransaction() which operate on thread local SqlMapClient instance
When running the application under multiple threads, it seems to get stuck on update on same table...
Did anyone notice this earlier?
Any solutions ...?
Regards
Ejaz
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org