EAserver - How to implement Spring's JdbcTemplate inside a POJO component.

Author

How to implement Spring's JdbcTemplate inside a POJO component.

Marty Jones

2005-11-21, 8:25 pm

We are looking at trying to incorporate Spring's support for JDBC within
POJO Java components and we are hitting a few roadblocks.

To give a little background, we are running EAS4.2 on Windows platform. We
are currently using com.sybase.jaguar.jcm.JCMCache to get a jdbc database
connection within our java components.

In order for us to use spring's JdbcTemplate class, we need to be able to
set a javax.sql.DataSource. I see that you can do a jndi lookup for
javax.sql.DataSource within EAServer but I am not sure the differences
between doing a jndi lookup versus JCMCache.getConnection(). Does anyone
know how you can force a new connection object when doing a jndi lookup like
you can when using JCMCache? Also how do you return the connection back to
the connection pool once you are done with it if you used a jndi lookup to
get the datasource?

Any help would be greatly appreciated.

Mark Maslow

2005-11-22, 1:24 pm

I use a javax.sql.DataSource that I map to a connection cache in the web
app properties. Then open and close the connection as usual. This
makes the app portable, and AFAIK, is the only way that works
generically, in any J2EE server. I believe JCMCache is EAS specific.

Don't really understand when using JCMCache class is appropriate to use.
Would be nice if someone at Sybase would explain that a little better
than the manual.

In article <4382427f$1@forums-1-dub>, marty_jones@dailyacc
ess.com
says...
> We are looking at trying to incorporate Spring's support for JDBC within
> POJO Java components and we are hitting a few roadblocks.
>
> To give a little background, we are running EAS4.2 on Windows platform. We
> are currently using com.sybase.jaguar.jcm.JCMCache to get a jdbc database
> connection within our java components.
>
> In order for us to use spring's JdbcTemplate class, we need to be able to
> set a javax.sql.DataSource. I see that you can do a jndi lookup for
> javax.sql.DataSource within EAServer but I am not sure the differences
> between doing a jndi lookup versus JCMCache.getConnection(). Does anyone
> know how you can force a new connection object when doing a jndi lookup like
> you can when using JCMCache? Also how do you return the connection back to
> the connection pool once you are done with it if you used a jndi lookup to
> get the datasource?
>
> Any help would be greatly appreciated.
>
>
>
>
>

a Friend

2005-11-23, 7:24 am

You can use Jaguar Apis if:
You want extra control over getting a connection
The database you're using doesn't have a JDBC 2.0 driver
available
You need to support legacy code

For example:
Connection conn = cache. getConnection(JCMCac
he.JCM_FORCE);

Regards
A friend...
[color=darkred]
> I use a javax.sql.DataSource that I map to a connection
> cache in the web app properties. Then open and close the
> connection as usual. This makes the app portable, and
> AFAIK, is the only way that works generically, in any
> J2EE server. I believe JCMCache is EAS specific.
>
> Don't really understand when using JCMCache class is
> appropriate to use. Would be nice if someone at Sybase
> would explain that a little better than the manual.
>
> In article <4382427f$1@forums-1-dub>,
> marty_jones@dailyacc
ess.com says...
> between doing a jndi lookup versus
> force a new connection object when doing a jndi lookup

Jonathan Baker [Sybase]

2005-11-30, 3:24 am

The JCMCache code is there for backwards compatibility - it existed
before Sun came out with the DataStore objects. It's all deprecated now
- it might be supported in EAServer 6.0, but I wouldn't count on it.

J

Mark Maslow wrote:[color=darkred
]
> I use a javax.sql.DataSource that I map to a connection cache in the web
> app properties. Then open and close the connection as usual. This
> makes the app portable, and AFAIK, is the only way that works
> generically, in any J2EE server. I believe JCMCache is EAS specific.
>
> Don't really understand when using JCMCache class is appropriate to use.
> Would be nice if someone at Sybase would explain that a little better
> than the manual.
>
> In article <4382427f$1@forums-1-dub>, marty_jones@dailyacc
ess.com
> says...

Marty Jones

2005-11-30, 7:24 am

Jonathan,

Can you explain how connection maintenance is handled using a JNDI lookup?
By that I mean, how do you force a new connection if the connection limit
(EAServer setting on cache) has been reached? Also how do you put the
connection back in the cache?

Thanks,

Marty

"Jonathan Baker [Sybase]" < last_name_first_init
ial@sybase.com> wrote in
message news:438d4879$1@foru
ms-1-dub...[color=darkred]
> The JCMCache code is there for backwards compatibility - it existed before
> Sun came out with the DataStore objects. It's all deprecated now - it
> might be supported in EAServer 6.0, but I wouldn't count on it.
>
>
> J
>
>
>
> Mark Maslow wrote:

Jonathan Baker [Sybase]

2005-11-30, 11:24 am

Marty:

Sure!

Retrieving a connection from a DataSource object is just like pulling
one from the JCMCache system. It returns an attached Connection object
right from the pool. The only difference is that you send it back to
the pool by calling Connection.close(). (The close() method is
overridden to return to the cache rather than actually closing the
connection.)

DataSource objects always draw out connections using the "WAIT"
property, and not the "FORCE" property. That has caused a lot of "teeth
gnashing" from our programmer friends who use FORCE, but there is a good
reason for it.

The problem with JCM_FORCE is that it doesn't give any control at all to
the system administrator. If they set a cache size at a particular
amount, it is always overridden. And, creating a one shot connection is
very expensive, so if you are doing it a lot then something is wrong.
The best way to use connection pooling is to set the cache with a
maximum limit high enough to allow all components to run, and use
JCM_WAIT. That way, if the admin needs to limit the connections (for
whatever reason) your code works in those boundaries.

Basically, JCM_FORCE is cheating, and bad programming. And everyone
knows it (and uses it anyway).

Does that answer your question?

Jonathan

Marty Jones wrote:
> Jonathan,
>
> Can you explain how connection maintenance is handled using a JNDI lookup?
> By that I mean, how do you force a new connection if the connection limit
> (EAServer setting on cache) has been reached? Also how do you put the
> connection back in the cache?
>
> Thanks,
>
> Marty
>
>
>
> "Jonathan Baker [Sybase]" < last_name_first_init
ial@sybase.com> wrote in
> message news:438d4879$1@foru
ms-1-dub...
>
>

Marty Jones

2005-11-30, 8:25 pm

Jonathan,

You have definetly answered my question.

Thanks for the info,

Marty

"Jonathan Baker [Sybase]" < last_name_first_init
ial@sybase.com> wrote in
message news:438de1af$1@foru
ms-1-dub...[color=darkred]
> Marty:
>
> Sure!
>
> Retrieving a connection from a DataSource object is just like pulling one
> from the JCMCache system. It returns an attached Connection object right
> from the pool. The only difference is that you send it back to the pool
> by calling Connection.close(). (The close() method is overridden to
> return to the cache rather than actually closing the connection.)
>
> DataSource objects always draw out connections using the "WAIT" property,
> and not the "FORCE" property. That has caused a lot of "teeth gnashing"
> from our programmer friends who use FORCE, but there is a good reason for
> it.
>
> The problem with JCM_FORCE is that it doesn't give any control at all to
> the system administrator. If they set a cache size at a particular
> amount, it is always overridden. And, creating a one shot connection is
> very expensive, so if you are doing it a lot then something is wrong. The
> best way to use connection pooling is to set the cache with a maximum
> limit high enough to allow all components to run, and use JCM_WAIT. That
> way, if the admin needs to limit the connections (for whatever reason)
> your code works in those boundaries.
>
> Basically, JCM_FORCE is cheating, and bad programming. And everyone knows
> it (and uses it anyway).
>
> Does that answer your question?
>
>
> Jonathan
>
>
> Marty Jones wrote:

Sponsored Links