REQUEST scope / JPA - many connections per request - help!

[Wayne]

Hi,

we have set up using warp persist with JPA using the per request idiom
on tomcat and jetty. When we make a web request however I see that
hibernate is opening and closing many connections to the database per
web request:

2010-10-12 12:40:35,843 [btpool0-3] DEBUG (ConnectionManager.java:421)
- opening JDBC connection
2010-10-12 12:40:35,846 [btpool0-3] DEBUG (ConnectionManager.java:404)
- aggressively releasing JDBC connection
2010-10-12 12:40:35,846 [btpool0-3] DEBUG (ConnectionManager.java:441)
- releasing JDBC connection [ (open PreparedStatements: 0, globally:
0) (open ResultSets: 0, globally: 0)]
2010-10-12 12:40:35,847 [btpool0-3] DEBUG (ConnectionManager.java:421)
- opening JDBC connection
2010-10-12 12:40:35,851 [btpool0-3] DEBUG (ConnectionManager.java:404)
- aggressively releasing JDBC connection
2010-10-12 12:40:35,851 [btpool0-3] DEBUG (ConnectionManager.java:441)
- releasing JDBC connection [ (open PreparedStatements: 0, globally:
0) (open ResultSets: 0, globally: 0)]
2010-10-12 12:40:35,852 [btpool0-3] DEBUG (ConnectionManager.java:404)
- aggressively releasing JDBC connection
2010-10-12 12:40:35,853 [btpool0-3] DEBUG (ConnectionManager.java:421)
- opening JDBC connection
2010-10-12 12:40:35,857 [btpool0-3] DEBUG (ConnectionManager.java:404)
- aggressively releasing JDBC connection
2010-10-12 12:40:35,858 [btpool0-3] DEBUG (ConnectionManager.java:441)
- releasing JDBC connection [ (open PreparedStatements: 0, globally:
0) (open ResultSets: 0, globally: 0)]
2010-10-12 12:40:35,859 [btpool0-3] DEBUG (ConnectionManager.java:421)
- opening JDBC connection

etc..

I thought that the whole point of pre-request setup was to have a
single session and therefore connection to the DB, so that the
transaction can be rolled back?
What so I need to do to have a single connection per request?

The code:
static {
PersistenceStrategy jpa = JpaPersistenceStrategy.builder()
.properties(new Properties())
.build();

Module m = PersistenceService.using(jpa).across(UnitOfWork.REQUEST)
.forAll(Matchers.any(),
Matchers.annotatedWith(Transactional.class))
.buildModule();

injector = Guice.createInjector(m, new InjectionModule());
}

<snip>
@Inject
ServiceInitializer(PersistenceService service) {
// initialize warp-persist for JPA
service.start();

}


persistence.xml:
<persistence-unit name="hubPersistenceUnit" transaction-
type="RESOURCE_LOCAL">

<properties>

<property name="hibernate.show_sql" value="false"/>
<property name="hibernate.connection.driver_class"
value="com.mysql.jdbc.Driver"/>
<property name="hibernate.connection.username" value="foo"/>
<property name="hibernate.connection.password" value="password"/>
<property name="hibernate.connection.autoReconnect" value="true"/>
<property name="hibernate.connection.autocommit" value="false"/>
<property name="hibernate.connection.url" value="jdbc:mysql://
localhost/hub?useUnicode=true&amp;characterEncoding=utf-8"/>
<property name="hibernate.current_session_context_class"
value="managed"/>
<property name="hibernate.dialect"
value="org.hibernate.dialect.MySQL5InnoDBDialect"/>
<property name="hibernate.cache.use_second_level_cache"
value="false"/>
<property name="hibernate.generate_statistics" value="false"/>
<property name="hibernate.jdbc.batch_size" value="100"/>


<property name="hibernate.c3p0.min_size" value="2"/>
<property name="hibernate.c3p0.max_size" value="3"/>
<property name="hibernate.c3p0.timeout" value="900"/>

<property name="hibernate.c3p0.numHelperThreads" value="4"/>
<property name="hibernate.c3p0.max_statements" value="400"/>

</properties>
</persistence-unit>

[Dhanji R. Prasanna]

Hi, 

The config looks OK to me. Are you sure that PersistenceFilter is running for each request? That may be your problem.

Dhanji.

--
You received this message because you are subscribed to the Google Groups "warp-core" group.
To post to this group, send email to warp...@googlegroups.com.
To unsubscribe from this group, send email to warp-core+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/warp-core?hl=en.

[Wayne Pope]

Hi,

yes it present in the web.xml and you can see it in the stack trace:

at com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:506)
at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:525)
at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128)
at org.hibernate.connection.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:56)
at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423)
at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1547)
at org.hibernate.loader.Loader.doQuery(Loader.java:673)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1860)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3049)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:399)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:98)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
at org.hibernate.impl.SessionImpl.immediateLoad(SessionImpl.java:836)
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:66)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:150)
at hub.app.model.Company$$EnhancerByCGLIB$$6e9c856b.getStyle(<generated>)
at hub.app.wicket.app.HubSession.loadUser(HubSession.java:117)
at hub.app.wicket.app.HubSession.attach(HubSession.java:102)
at org.apache.wicket.Session.set(Session.java:277)
at org.apache.wicket.Session.findOrCreate(Session.java:237)
at org.apache.wicket.protocol.http.WicketFilter.getLastModified(WicketFilter.java:1169)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:307)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:769)
at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:698)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:891)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:619)

It seems that for every query not marked with a @Transaction is still
opens and closes the connection. Do I need to put a @Transaction at
the highest level of code ie in my wicket page ?

[Dhanji R. Prasanna]

Hmm, that is very odd indeed. No you do not need @Transactional higher up, it only should open and close transactions, not sessions.

Aha, I think I know what it is--Warp-persist's transaction interceptor is not running at all. I suspect this is due to Wicket's magic--wicket does support Guice-created classes properly. It creates its own proxies and then sets Guice's fields. So your code is not being processed for transactions, and it looks like it is not obtaining the same session either.

I suggest creating a pure Guice class that loads your users (so inject a Dao or something that is fully created by Guice)

You need to see something like JpaLocalTxnInterceptor in your stack trace. Without it you know Guice and warp-persist are simply not running.

Dhanji.

[Dhanji R. Prasanna]

On Tue, Oct 12, 2010 at 10:58 PM, Dhanji R. Prasanna <dha...@gmail.com> wrote:

Hmm, that is very odd indeed. No you do not need @Transactional higher up, it only should open and close transactions, not sessions.

Aha, I think I know what it is--Warp-persist's transaction interceptor is not running at all. I suspect this is due to Wicket's magic--wicket does support Guice-created classes properly. It creates its own proxies and then sets Guice's

does NOT...

 

Btw, you may want to migrate to guice-persist as that supersedes warp-persist and has a slightly nicer API.

Dhanji

[Wayne Pope]

So somehow wicket is interfering with guice? I create my Module in
static in the wicket Application and the binding is done there. I'm a
newbe to guice so don;t really understand the in's and out's!

>I suggest creating a pure Guice class that loads your users (so inject a Dao or something that is fully created by Guice)

Not really sure what you mean here, could you expand a little on this?
All the dao are in our 'service' layer, so typically to get the list
of users you call something like
ServiceLocator.getUserService().getUsers()

ServiceLocator being:
public class ServiceLocator {
@Inject private static Provider<IUserService> userService;
etc

Is that not directly injected by guice?

Will moving to guice-persis actually solve this problem though?

thanks for your help on this - I've been stuck on this a week now!

[Wayne Pope]

Oh BTW I'm only using guice 2 directly.
I wasn't even aware there is a wicket guice project -not sure what the
difference is..?!

[Dhanji R. Prasanna]

On Tue, Oct 12, 2010 at 11:14 PM, Wayne Pope <waynemai...@googlemail.com> wrote:

So somehow wicket is interfering with guice? I create my Module in
static in the wicket Application and the binding is done there. I'm a
newbe to guice so don;t really understand the in's and out's!

>I suggest creating a pure Guice class that loads your users (so inject a Dao or something that is fully created by Guice)

Not really sure what you mean here, could you expand a little on this?
All the dao are in our 'service' layer, so typically to get the list
of users you call something like
ServiceLocator.getUserService().getUsers()

I would suggest not using a ServiceLocator but injecting the provider directly. It seems likely to me that it is injected by Guice. But I think they way Wicket uses Guice is very odd. Wicket does not allow Guice to inject its page classes (unlike Sitebricks or Struts).

Well, moving to guice-persist won't help you, but warp-persist is no longer maintained so if you want any bugfixes or benefit from improvements you should switch to GP.

From your original code--you're just creating a Guice injector and throwing it away in your static {} block. You need to bind it to Wicket somehow. There should be details on the Wicket site on how to do this. IIRC something like a GuiceComponentInstantation or something like that...

Dhanji.

[Wayne Pope]

Hi Dhanji,

>they way Wicket uses Guice is very odd.

But I don't see how wicket can effect guices injection? I'm not using
the wicket-guice project, just guice directly.

>I would suggest not using a ServiceLocator but injecting the provider
> directly.

You mean inject Provider<IUserService> userService into the wicket
pages/components? How will this change anything?

>You need to bind it to Wicket somehow.

So you think I need to use the wicket guice project? Do you think this
make the warp persist tx inceptor get picked up?

thanks

On Tue, Oct 12, 2010 at 2:34 PM, Dhanji R. Prasanna <dha...@gmail.com> wrote:

> I would suggest not using a ServiceLocator but injecting the provider
> directly. It seems likely to me that it is injected by Guice. But I think
> they way Wicket uses Guice is very odd. Wicket does not allow Guice to
> inject its page classes (unlike Sitebricks or Struts).
> Well, moving to guice-persist won't help you, but warp-persist is no longer
> maintained so if you want any bugfixes or benefit from improvements you
> should switch to GP.
> From your original code--you're just creating a Guice injector and throwing
> it away in your static {} block. You need to bind it to Wicket somehow.
> There should be details on the Wicket site on how to do this. IIRC something
> like a GuiceComponentInstantation or something like that...
> Dhanji.
>

[Wayne Pope]

>You need to bind it to Wicket somehow

I updated the code and included the wicket guice project and added the line:

addComponentInstantiationListener(new GuiceComponentInjector(this, injector));

However this has no effect at all - I still get loads of connections
opening and closing per web request.
I'm getting desperate with this now - any other ideas what this could be?

[Wayne Pope]

It seems at the moment, the only time JpaLocalTxnInterceptor is in the
call stack is if a dao method is explicitly mark by a @Transaction.
which kind of defeats the purpose.

Really stuck on this.

[Dan Retzlaff]

The red flags here are these logging statements:

DEBUG (ConnectionManager.java:404) - aggressively releasing JDBC connection

If you dig into ConnectionManager code, you'll see that this implies some kind of connection pool configuration whereby the connection is released after every single prepared statement.

To clarify Dhanji's comments on Wicket, wicket's GuiceComponentInjector supports injection of all Component's, including pages. What it does not support is constructor injection and AOP proxies, since the Wicket idiom for component creation uses the "new" operator instead of Injector.getInstance(). That addComponentInstantationListener() call makes the constructor of the base class of all Wicket components to look for @Inject annotated things and satisfy their dependencies through Guice. It's actually kind of weird because you end up with your @Inject annotated setters being called before your derived class' constructor. Anyway, none of this is relevant to your current problems.

Dan

[Wayne W]

Hi Dan,

> The red flags here are these logging statements:
> DEBUG (ConnectionManager.java:404) - aggressively releasing JDBC connection
> If you dig into ConnectionManager code, you'll see that this implies some
> kind of connection pool configuration whereby the connection is released
> after every single prepared statement.

And this is the exact issue I'm trying to solve. I don't have any
problems with using wicket/hibernate/warp/jpa - it works fine - the
problem is the connection/session management. To my eyes this just
looks wrong - from my (basic) understanding when using JPA the
entitymanager looks after the session and connections and I thought
that warp persist would control the session per web request and
therefore a connection per web request. But I'm seeing many
connections per web request.
Have I got it wrong?

I even started from scratch and used a quick start with a very basic
setup, but I still see the same issue of multiple connections per
request - so I'm getting to the point where I just don;t think warp
manages the connection via the entity manager (at least on jetty) when
using UnitOfWork.REQUEST. From reading the documentation I thought
that is meant a session per (web) request.

It only works on keeping the connection open when I explicitly use the
@Transaction on a method.

Thanks for the clarification on wicket and guice.

[Dan Retzlaff]

I've never seen this situation myself, but it looks like the release mode is configured in org.hibernate.cfg.SettingsFactory with the "hibernate.connection.release_mode" property. The default, "auto", defers to the transaction factory. Try explicitly setting that property to "on_close". You might need to bust out the debugger to figure out how exactly you get into this aggressive release mode.

There may not be anything wrong here. For properly pooled connections, "releasing" it to the pool is a cheap operation, and does not imply any network operations.

[Dhanji R. Prasanna]

On Wed, Oct 13, 2010 at 12:59 AM, Wayne Pope <waynemai...@googlemail.com> wrote:

It seems at the moment, the only time JpaLocalTxnInterceptor is in the
call stack is if a dao method is explicitly mark by a @Transaction.

Does it work if JpaLocalTxnInterceptor is in the call stack? Or are you calling the session from elsewhere so this can't be verified? I would suggest you first track down this problem (basically this interceptor will only run on methods marked @Transactional and on non-Wicket classes).

 

which kind of defeats the purpose.

It is, in fact, the stated behavior =)

This is because you have explicitly configured it like this. WP will NOT catch methods NOT marked with @Transactional. If you want all methods to be intercepted you must annotate them. Or annotate their classes with @Transactional, in which case you need to switch your forAll() to forAll(annotatedWith(Transactional.class), any());

WP has been working for a lot of people and there are many tests asserting this particular case, so I suspect you just need to narrow down why your interceptors are not being called (Wicket / Guice thing). 

If you are desperate and suspect a bug in trunk code, try switching to WP 1.0 downloadable jar from the warp persist--this is in production in many projects including at Google.

Dhanji.

[Wayne W]

Hi Dhanji,

>WP will NOT catch methods NOT marked with @Transactional.

Ok well I think this is the root of my problem and understanding.

thanks for you help on this (and Dan!) - much appreciated.

[Dhanji R. Prasanna]

On Wed, Oct 13, 2010 at 3:43 PM, Wayne W <waynemai...@googlemail.com> wrote:

Hi Dhanji,

>WP will NOT catch methods NOT marked with @Transactional.

Ok well I think this is the root of my problem and understanding.

This is easily changed if you use class matchers...

Note that you can't do anything with a SQL database if it's not inside a transaction anyway, so it doesn't make sense to call hibernate from non-@Transactional methods. That's why you're seeing this weird session creation/destruction.

Dhanji.

[Wayne W]

yes understood.

I just thought that we'd be using a single DB connection/session per
WEB request, rather than per Transaction. Its what I understood from
reading the documentation.

[Dhanji R. Prasanna]

It *IS* a single DB session per web request. You're having some very strange problems indeed! =)

All Im saying is, if you do not access the session for the WEB request VIA an @Transactional method, it wont work.

Does that help a bit?

Dhanji.

[Wayne W]

Ok let make sure we're on the same page!

I've taken a wicket/warp/jpa architype quick start from here:
http://jweekend.co.uk/dev/LegUp

Executing a single web request:

Request->
Start page constructor -> eventDao.findAll()
-> eventDao.countAll()
end
Response <-

Dao code:

public class EventDaoJPAImp extends AbstractDaoJPAImpl<Event>
implements EventDao {

public EventDaoJPAImp() {
super(Event.class);
}

@Transactional
public List<Event> findAll() {
Exception e = new Exception();
e.fillInStackTrace();
e.printStackTrace();
TypedQuery<Event> query1 = em.get().createQuery("select e from Event
e", Event.class);

return query1.getResultList();
}

@Transactional
public int countAll() {
Exception e = new Exception();
e.fillInStackTrace();
e.printStackTrace();
TypedQuery<Long> query = em.get().createQuery("select count (e) from
Event e", Long.class);
return (query.getSingleResult()).intValue();
}
}

Output:

at com.mycompany.data.dao.jpa.EventDaoJPAImp.findAll(EventDaoJPAImp.java:25)
at com.mycompany.data.dao.jpa.EventDaoJPAImp$$EnhancerByGuice$$dd1bcb44.CGLIB$findAll$0(<generated>)
at com.mycompany.data.dao.jpa.EventDaoJPAImp$$EnhancerByGuice$$dd1bcb44$$FastClassByGuice$$3284d220.invoke(<generated>)
at com.google.inject.internal.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:64)
at com.wideplay.warp.persist.jpa.JpaLocalTxnInterceptor.invoke(JpaLocalTxnInterceptor.java:68)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:64)
at com.google.inject.InterceptorStackCallback.intercept(InterceptorStackCallback.java:44)
at com.mycompany.data.dao.jpa.EventDaoJPAImp$$EnhancerByGuice$$dd1bcb44.findAll(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler.invoke(LazyInitProxyFactory.java:416)
at org.apache.wicket.proxy.$Proxy11.findAll(Unknown Source)
at com.mycompany.pages.EventPage.<init>(EventPage.java:38)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:188)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:65)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:298)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:320)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

Hibernate: select event0_.id as id0_, event0_.location as location0_,
event0_.title as title0_ from test_event event0_
DEBUG - ConnectionManager - aggressively releasing JDBC connection
DEBUG - ConnectionManager - releasing JDBC connection [ (open

PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]

java.lang.Exception
at com.mycompany.data.dao.jpa.EventDaoJPAImp.countAll(EventDaoJPAImp.java:35)
at com.mycompany.data.dao.jpa.EventDaoJPAImp$$EnhancerByGuice$$dd1bcb44.CGLIB$countAll$1(<generated>)
at com.mycompany.data.dao.jpa.EventDaoJPAImp$$EnhancerByGuice$$dd1bcb44$$FastClassByGuice$$3284d220.invoke(<generated>)
at com.google.inject.internal.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:64)
at com.wideplay.warp.persist.jpa.JpaLocalTxnInterceptor.invoke(JpaLocalTxnInterceptor.java:68)
at com.google.inject.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:64)
at com.google.inject.InterceptorStackCallback.intercept(InterceptorStackCallback.java:44)
at com.mycompany.data.dao.jpa.EventDaoJPAImp$$EnhancerByGuice$$dd1bcb44.countAll(<generated>)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.wicket.proxy.LazyInitProxyFactory$JdkHandler.invoke(LazyInitProxyFactory.java:416)
at org.apache.wicket.proxy.$Proxy11.countAll(Unknown Source)
at com.mycompany.pages.EventPage.<init>(EventPage.java:71)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:188)
at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:65)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:298)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:320)
at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:234)
at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92)
at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250)
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1436)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:545)
at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:484)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:317)
at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)

at com.wideplay.warp.persist.PersistenceFilter$3.run(PersistenceFilter.java:141)
at com.wideplay.warp.persist.internal.Lifecycles.failEarlyAndLeaveNoOneBehind(Lifecycles.java:29)
at com.wideplay.warp.persist.PersistenceFilter.doFilter(PersistenceFilter.java:155)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
DEBUG - ConnectionManager - opening JDBC connection
Hibernate: select count(event0_.id) as col_0_0_ from test_event event0_ limit ?
DEBUG - ConnectionManager - aggressively releasing JDBC connection
DEBUG - ConnectionManager - releasing JDBC connection [ (open

PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)]

Here you can clearly see to connections being opened and
JpaLocalTxnInterceptor in the call stack. Is this what you expect?