Tim, Jetty is run frequently together with Jersey and Neo4j. There is no sign of any of these Exceptions coming from Neo4j code. However, could you please provide (maybe off-list) some example code so we can take a look at it?
Cheers, /peter neubauer COO and Sales, Neo Technology GTalk: neubauer.peter Skype peter.neubauer Phone +46 704 106975 LinkedIn http://www.linkedin.com/in/neubauer Twitter http://twitter.com/peterneubauer http://www.neo4j.org - Your high performance graph database. http://gremlin.tinkerpop.com - The terminal to the Giant Global Graph. On Wed, Jan 27, 2010 at 9:02 AM, Tim Langley <timlang...@me.com> wrote: > hi Johan > > thank you for the reply - i think you're right :) (hope so) > I'm currently using jetty as the web-server and these exceptions are > all being thrown by jetty > > example (and sorry for the dump) > com.sun.jersey.api.container.MappableContainerException: > java.lang.Exception: Unable to return Neo - This is not in a transaction > at > com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch > (ResourceJavaMethodDispatcher.java:74) > at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept > (HttpMethodRule.java:166) > at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept > (RightHandPathRule.java:114) > at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept > (ResourceClassRule.java:74) > at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept > (RightHandPathRule.java:114) > at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept > (RootResourceClassesRule.java:66) > at > com.sun.jersey.server.impl.application.WebApplicationImpl > ._handleRequest(WebApplicationImpl.java:658) > at > com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest > (WebApplicationImpl.java:616) > at > com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest > (WebApplicationImpl.java:607) > at com.sun.jersey.spi.container.servlet.WebComponent.service > (WebComponent.java:309) > at com.sun.jersey.spi.container.servlet.ServletContainer.service > (ServletContainer.java:425) > at com.sun.jersey.spi.container.servlet.ServletContainer.service > (ServletContainer.java:590) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) > at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java: > 511) > at org.mortbay.jetty.servlet.ServletHandler.handle > (ServletHandler.java:390) > 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: > 418) > at org.mortbay.jetty.handler.ContextHandlerCollection.handle > (ContextHandlerCollection.java:230) > at org.mortbay.jetty.handler.HandlerCollection.handle > (HandlerCollection.java:114) > 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.content > (HttpConnection.java:938) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:755) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:218) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) > at org.mortbay.io.nio.SelectChannelEndPoint.run > (SelectChannelEndPoint.java:409) > at org.mortbay.thread.QueuedThreadPool$PoolThread.run > (QueuedThreadPool.java:582) > > When Jetty start's up it reports: > 2010-01-26 13:23:18.650:INFO::No Transaction manager found - if your > webapp requires one, please configure one. > > which is what got me starting thinking about this > > I'd really appreciate any guidance on: > a) do I need to configure neo or jetty better > b) should I take jetty out of the equation and use a different web- > server (Tomcat?) > > I'm wandering round in the dark here - would appreciate any thoughts :) > > T > > > On 26 Jan 2010, at 20:34, Johan Svensson wrote: > >> Hi, >> >> This sounds like a scala wrapper issue. >> >> Short lived write transactions together with long lived reads should >> be no problem. By default no locks are taken during reads instead each >> read operation behaves as if it took a snapshot of the graph >> (committed state) at point of invocation. So to answer your questions: >> >> 1. Neo4j is by default configured to handle concurrent access. >> >> 2. Neo4j read operations will not block a write operation and vice >> versa since by default no read lock is taken. >> >> Could you provide some more detailed error message or maybe any of the >> scala people know what could be wrong? >> >> Regards, >> >> -Johan >> >> On Tue, Jan 26, 2010 at 5:51 PM, Tim Langley <timlang...@me.com> >> wrote: >>> hi guys and girls >>> >>> I'm currently running Neo as a web-service - exposed through a SCALA >>> based REST API >>> The web service essentially does two tasks >>> >>> a) transactional - allowing the creation and modification of nodes >>> - these require read write locks but each one is relatively short in >>> duration >>> >>> b) reporting >>> - this requires only read locks but each query can be several seconds >>> in duration (esp for larger data-sets) >>> >>> When the web-service is running at (even medium) load then I'm >>> getting >>> a lot of java exceptions >>> "java.lang.Exception: Unable to return Neo - This is not in a >>> transaction" >>> >>> two little questions please (and as likely or not these are down to >>> my >>> lack of understanding) >>> >>> 1. how can i configure neo (or do I need a wrapper) to manage the >>> concurrency so that I don't get these errors >>> >>> 2. for the reporting function can I get read only locks which will >>> not >>> block the read-write locks >>> >>> Thank you inadvance >>> >>> Yours >>> >>> Tim >> _______________________________________________ >> Neo mailing list >> User@lists.neo4j.org >> https://lists.neo4j.org/mailman/listinfo/user > > Tel: +44 7989 539363 > Email: ...@timlangley.me.uk > Web: http://www.linkedin.com/in/langleytim > > _______________________________________________ > Neo mailing list > User@lists.neo4j.org > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
