Even if you don't use a full app server, there are several connection pooling
libraries you could use:
http://www.primrose.org.uk/home.jsp
http://sourceforge.net/projects/c3p0
http://jakarta.apache.org/commons/dbcp/
View the original post :
We are not using transactions.
Keeping the connections open and reusable was the intent; our information
obtained earlier was that this scenario could not run at all and we needed to
use a connection pool - however that does not suit our purpose as it would
require significant alteration of
Fair enough. The problem here though is that when using transactions that span
multiple calls, this breaks things.
A proper solution would be to use a rudimentary internal pool (HashMap of open
conns) for the non-managed factory.
View the original post :
Agreed - however we are doing limited, time-bound feasibility studies of many
competing combinatorials in order to see if we should make a recommendation for
a specific direction. If this is the direction we take, a connection pool is
mandatory - but likely would be the job of the container /
Adding the following additional change allowed for 10,000 consecutive updates
without error.
public NonManagedConnectionFactory(String url, String usr, String pwd)
{
this.url = url;
this.usr = usr;
this.pwd = pwd;
// what if I do a
What does this change actually do? It just seems to create a new connection
and store it in threadlocal when the cacheloader is constructed, and that's it.
So all it does is store a conn for a particular thread (the one that starts the
cache). Other threads will still have to call
[EMAIL PROTECTED] wrote : What does this change actually do? It just seems
to create a new connection and store it in threadlocal when the cacheloader is
constructed, and that's it.
|
| So all it does is store a conn for a particular thread (the one that starts
the cache). Other threads
Ah, here's a reason why - are you running your test within a transaction?
Non-tx-related calls call cf.close(), which results in:
| public void close(Connection con)
| {
| if(con != null con != connection.get())
| {
| try
| {
|
Thanks. See http://jira.jboss.com/jira/browse/JBCACHE-802
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3977016#3977016
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3977016
___
After running a large number of tests, all of which repeatably and consistently
fail in and around approximately 1970-1990 cache updates, I have made the
following change.
After this change, the code then fails between 3900-4000 updates. It appears
that this is a minor defect or at least a
This is possibly due to the fact that you run out of DB connections. Are you
running JBC within an app server? I'd recommend using a pool of connections.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3975468#3975468
Reply to the post :
By the way I am running on WinXP professional edition with SP2
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3974543#3974543
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3974543
12 matches
Mail list logo
