Load Balancing in Geronimo
I'm working with a University that wants to implement an application on Geronimo that supports 10,000 concurrent users. There are a number of use cases but here's one that captures the primary issue Will this scenario work in the absence of clustering: 1. Load balancer in front of many linux servers each running Geronimo 2. Each instance or Geronimo connected to the same database server 3. Application only composed of JSPs, Servlets and Javabeans (no EJBs) 4. Users will be accessing shared data such as registering for a class In this case, if the following is true: 1. Load balancer handles session stickiness 2. Database server handles transactional access to shared data 3. Users can live without session failover Will this work? What are the unforeseen problems? What are the unforeseen restrictions? May thanks for any and all feedback. Michael Malgeri Mgr Gluecode Client Technical Services CELLULAR: 310-704-6403
Re: Petstore with Geronimo M5 ?
Carla Cremers wrote: Any clues ? It's much better now. I've just applied a fix to make it work as described at http://wiki.apache.org/geronimo/PetStore. Download the latest sources (make sure it's revision 328497 or higher) and give it a try again. You'll be surprised to see the green parrot in your browser ;) Thanks again for the head-up! Jacek
Re: web applications and hosting containers
David Jencks wrote: On Oct 25, 2005, at 8:42 AM, Joe Bohn wrote: The default Geronimo configuration includes both the Jetty and Tomcat web containers predeployed and started by default. I'm hoping we can find a way soon so this is not the case. Therefore, it would follow (when dealing with a web application that is not dependent upon any specific web container) that the web app would either: 1) upon a single deployment be capable of running in either a single, all, or any combination of containers. If this is the case then I expect that the container would somehow be specified when starting the application or the application would be started concurrently on all active containers (hence a runtime choice of container). 2) require the specification of a container(s) in the deploy command. The web app could then be deployed multiple times (once to each web container). The individually deployed applications could then be started independently on each container. However, it appears that there is no mechanism to reference a specific container from either the deploy command or the start command. How is the user supposed to interpret this? What behavior should the user expect when deploying and starting web applications that have no need for a container specific plan and hence include no geronimo deployment plan? To which container(s) are they deployed? Is the choice of the container a deployment decision (deploy command) or a run-time decision (start/stop command)? There are 2 factors that can affect the web container a web app gets deployed to: 1. namespace of the deployment plan. There are 3 choices: a. jetty specific http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0 A plan with this namespace will only get deployed to jetty. b. tomcat specific http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0 A plan with this namespace will only get deployed to tomcat c. generic http://geronimo.apache.org/xml/ns/j2ee/web-1.0 A plan with this namespace might get deployed to jetty or tomcat: Thanks for the clarification. I was just trying to understand the generic case (option c above). I suspect this it the situation for 99% of users building web applications to be deployed in Geronimo ... they could run in any container (as long as there is one) so their deployment plan will most likely not call out a specific container. 2. default namespace attribute in WebModuleBuilder. This should be set to (a) or (b) above. Web apps with no plan or web apps with the (c) namespace will get deployed to jetty or tomcat depending on the value of this attribute. Thanks ... that helps clarify things. IIUC then the only way to deploy applications to the tomcat container in the default configuration is to have a tomcat specific plan (option b above) because the WebBuilder namespace is set to Jetty in that configuration. I also now understand that the association between an application and a container is set at the time of deployment. Hence the application will always start on the container specified during deployment (IIF that container itself is started). I am against including a command line option to select the web container. I think that running both containers is a temporary expedient that with luck will disappear by 1.0, and corrupting the deployment architecture to accomodate it is unnecessary and unwise. thanks david jencks -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Daytrader Redux
FYI... I am not having any problem with this either. --- Nell Gawor <[EMAIL PROTECTED]> wrote: > Hi Carla, > > I just took another look at this. Before trying to register this new > user, did you do the following: > > Go to 'Configuration -> (Re)-populate Trade Database' and wait until the > quotes and users are created? > > You must do this before doing anything with dayTrader, otherwise there > isn't any data for it to work with (including the quotes it is trying to > retrieve in this step). I had forgotten this step with my latest > daytrader install but I just repopulated my database and I am not having > any problems creating new users. > > Thanks, > Nell > > Nell Gawor wrote: > > > Hi Carla, > > > > It's not working for me either -- I always use the default user so I > > have never tried to register a new one. I think this (the exception > > you pasted below) is actually the exception you get on subsequent > > attempts to create a user you already tried to create -- the root > > exception appears to be a duplicate key because you are creating the > > same user twice in the database. > > > > So the user must get at least partially created. Still, the first > > attempt to create the user as well as attempts to log in as that user > > all fail with problems (NullPointerException) in the getMarketSummary > > method. I will take a look and see if I can figure out any more. > > > > Thanks, > > Nell > > > >> > >> *"Carla Cremers" <[EMAIL PROTECTED]>* > >> > >> 10/25/2005 01:33 AM > >> Please respond to > >> user@geronimo.apache.org > >> > >> > >> > >> To > >> > >> cc > >> > >> Subject > >> Daytrader Redux > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Many thanks to Nell Gawor ! After figuring out how to build svn. I > >> was able to download top of tree Geronimo and able to build and load > >> my database and deploy DayTrader and get to the web pages. I > >> created a user John Doe and got : > >> > >> Once again, any clues appreciated : > >> > >> *Processing request:*/daytrader/app * > >> StatusCode:* 500 * > >> Message:*TradeServletAction.doRegister(...) exception user =jdoe * > >> Exception:*java.rmi.RemoteException: Unable to commit container > >> transaction; nested exception is: javax.transaction.SystemException: > >> Unable to commit container transaction > >> java.rmi.RemoteException: Unable to commit container transaction; > >> nested exception is: javax.transaction.SystemException: Unable to > >> commit container transaction at > >> org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:138) > >> > >> at > >> org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3240b09e.register() > >> at > >> org.apache.geronimo.samples.daytrader.TradeAction.register(TradeAction.java:472) > >> > >> at > >> > org.apache.geronimo.samples.daytrader.web.TradeServletAction.doRegister(TradeServletAction.java:622) > > >> at > >> > org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:145) > > >> at > >> > org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:82) > > >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at > >> javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at > >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) > >> at > >> org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) > >> > >> at > >> > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) > > >> at > >> > org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:92) > > >> at > >> > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > > >> at > >> org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) > >> at > >> > org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) > > >> at > >> > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) > > >> at > >> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) > >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at > >> > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) > > >> at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at > >> org.mortbay.http.HttpServer.service(HttpServer.java:954) at > >> org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at > >> org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) > >> at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at > >> org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) > >> at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at > >> org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.ja
Re: web applications and hosting containers
On Oct 25, 2005, at 8:42 AM, Joe Bohn wrote: The default Geronimo configuration includes both the Jetty and Tomcat web containers predeployed and started by default. I'm hoping we can find a way soon so this is not the case. Therefore, it would follow (when dealing with a web application that is not dependent upon any specific web container) that the web app would either: 1) upon a single deployment be capable of running in either a single, all, or any combination of containers. If this is the case then I expect that the container would somehow be specified when starting the application or the application would be started concurrently on all active containers (hence a runtime choice of container). 2) require the specification of a container(s) in the deploy command. The web app could then be deployed multiple times (once to each web container). The individually deployed applications could then be started independently on each container. However, it appears that there is no mechanism to reference a specific container from either the deploy command or the start command. How is the user supposed to interpret this? What behavior should the user expect when deploying and starting web applications that have no need for a container specific plan and hence include no geronimo deployment plan? To which container(s) are they deployed? Is the choice of the container a deployment decision (deploy command) or a run-time decision (start/stop command)? There are 2 factors that can affect the web container a web app gets deployed to: 1. namespace of the deployment plan. There are 3 choices: a. jetty specific http://geronimo.apache.org/xml/ns/j2ee/web/jetty-1.0 A plan with this namespace will only get deployed to jetty. b. tomcat specific http://geronimo.apache.org/xml/ns/j2ee/web/tomcat-1.0 A plan with this namespace will only get deployed to tomcat c. generic http://geronimo.apache.org/xml/ns/j2ee/web-1.0 A plan with this namespace might get deployed to jetty or tomcat: 2. default namespace attribute in WebModuleBuilder. This should be set to (a) or (b) above. Web apps with no plan or web apps with the (c) namespace will get deployed to jetty or tomcat depending on the value of this attribute. I am against including a command line option to select the web container. I think that running both containers is a temporary expedient that with luck will disappear by 1.0, and corrupting the deployment architecture to accomodate it is unnecessary and unwise. thanks david jencks
web applications and hosting containers
The default Geronimo configuration includes both the Jetty and Tomcat web containers predeployed and started by default. Therefore, it would follow (when dealing with a web application that is not dependent upon any specific web container) that the web app would either: 1) upon a single deployment be capable of running in either a single, all, or any combination of containers. If this is the case then I expect that the container would somehow be specified when starting the application or the application would be started concurrently on all active containers (hence a runtime choice of container). 2) require the specification of a container(s) in the deploy command. The web app could then be deployed multiple times (once to each web container). The individually deployed applications could then be started independently on each container. However, it appears that there is no mechanism to reference a specific container from either the deploy command or the start command. How is the user supposed to interpret this? What behavior should the user expect when deploying and starting web applications that have no need for a container specific plan and hence include no geronimo deployment plan? To which container(s) are they deployed? Is the choice of the container a deployment decision (deploy command) or a run-time decision (start/stop command)? Thanks, Joe -- Joe Bohn [EMAIL PROTECTED] "He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Daytrader Redux
Hi Carla, I just took another look at this. Before trying to register this new user, did you do the following: Go to 'Configuration -> (Re)-populate Trade Database' and wait until the quotes and users are created? You must do this before doing anything with dayTrader, otherwise there isn't any data for it to work with (including the quotes it is trying to retrieve in this step). I had forgotten this step with my latest daytrader install but I just repopulated my database and I am not having any problems creating new users. Thanks, Nell Nell Gawor wrote: Hi Carla, It's not working for me either -- I always use the default user so I have never tried to register a new one. I think this (the exception you pasted below) is actually the exception you get on subsequent attempts to create a user you already tried to create -- the root exception appears to be a duplicate key because you are creating the same user twice in the database. So the user must get at least partially created. Still, the first attempt to create the user as well as attempts to log in as that user all fail with problems (NullPointerException) in the getMarketSummary method. I will take a look and see if I can figure out any more. Thanks, Nell *"Carla Cremers" <[EMAIL PROTECTED]>* 10/25/2005 01:33 AM Please respond to user@geronimo.apache.org To cc Subject Daytrader Redux Many thanks to Nell Gawor ! After figuring out how to build svn. I was able to download top of tree Geronimo and able to build and load my database and deploy DayTrader and get to the web pages. I created a user John Doe and got : Once again, any clues appreciated : *Processing request:*/daytrader/app * StatusCode:* 500 * Message:*TradeServletAction.doRegister(...) exception user =jdoe * Exception:*java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:138) at org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3240b09e.register() at org.apache.geronimo.samples.daytrader.TradeAction.register(TradeAction.java:472) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doRegister(TradeServletAction.java:622) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:145) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: javax.transaction.SystemException: Unable to commit container transaction at org.apache.geronimo.transaction.context.InheritableTransactionContext.rollbackAndThrow(InheritableTransactionContext.java:327) at org.apache.geronimo.transaction.context.InheritableTransactionContext.complete(InheritableTransactionContext.java:199) at org.apache.geronimo.transaction.context.InheritableTransactionContext.commit(InheritableTransactionContext.java:146) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:152) at org.openejb.transaction.TransactionContextInterceptor.invoke(Tran
Re: Daytrader Redux
Hi Carla, It's not working for me either -- I always use the default user so I have never tried to register a new one. I think this (the exception you pasted below) is actually the exception you get on subsequent attempts to create a user you already tried to create -- the root exception appears to be a duplicate key because you are creating the same user twice in the database. So the user must get at least partially created. Still, the first attempt to create the user as well as attempts to log in as that user all fail with problems (NullPointerException) in the getMarketSummary method. I will take a look and see if I can figure out any more. Thanks, Nell *"Carla Cremers" <[EMAIL PROTECTED]>* 10/25/2005 01:33 AM Please respond to user@geronimo.apache.org To cc Subject Daytrader Redux Many thanks to Nell Gawor ! After figuring out how to build svn. I was able to download top of tree Geronimo and able to build and load my database and deploy DayTrader and get to the web pages. I created a user John Doe and got : Once again, any clues appreciated : *Processing request:*/daytrader/app * StatusCode:* 500 * Message:*TradeServletAction.doRegister(...) exception user =jdoe * Exception:*java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:138) at org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3240b09e.register() at org.apache.geronimo.samples.daytrader.TradeAction.register(TradeAction.java:472) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doRegister(TradeServletAction.java:622) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:145) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: javax.transaction.SystemException: Unable to commit container transaction at org.apache.geronimo.transaction.context.InheritableTransactionContext.rollbackAndThrow(InheritableTransactionContext.java:327) at org.apache.geronimo.transaction.context.InheritableTransactionContext.complete(InheritableTransactionContext.java:199) at org.apache.geronimo.transaction.context.InheritableTransactionContext.commit(InheritableTransactionContext.java:146) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:152) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129) ... 26 more Caused by: org.tranql.ql.QueryException: Error executing statement: INSERT INTO AccountProfileEJB (address, password, userID, email, creditCard, fullName) VALUES (?, ?, ?, ?, ?, ?) at org.tranql.sql.jdbc.JDBCUpdateCommand.execute(JDBCUpdateCommand.java:69) at or
test mail - please ignore
Daytrader Redux
Many thanks to Nell Gawor ! After figuring out how to build svn. I was able to download top of tree Geronimo and able to build and load my database and deploy DayTrader and get to the web pages. I created a user John Doe and got : Once again, any clues appreciated : Processing request:/daytrader/app StatusCode: 500 Message:TradeServletAction.doRegister(...) exception user =jdoe Exception:java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction java.rmi.RemoteException: Unable to commit container transaction; nested exception is: javax.transaction.SystemException: Unable to commit container transaction at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:138) at org.openejb.proxy.SessionEJBObject$$EnhancerByCGLIB$$3240b09e.register() at org.apache.geronimo.samples.daytrader.TradeAction.register(TradeAction.java:472) at org.apache.geronimo.samples.daytrader.web.TradeServletAction.doRegister(TradeServletAction.java:622) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.performTask(TradeAppServlet.java:145) at org.apache.geronimo.samples.daytrader.web.TradeAppServlet.doGet(TradeAppServlet.java:82) at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:427) at org.apache.geronimo.jetty.JettyServletHolder.handle(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at org.apache.geronimo.samples.daytrader.web.OrdersAlertFilter.doFilter(OrdersAlertFilter.java:92) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(JSR154Filter.java:171) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:635) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: javax.transaction.SystemException: Unable to commit container transaction at org.apache.geronimo.transaction.context.InheritableTransactionContext.rollbackAndThrow(InheritableTransactionContext.java:327) at org.apache.geronimo.transaction.context.InheritableTransactionContext.complete(InheritableTransactionContext.java:199) at org.apache.geronimo.transaction.context.InheritableTransactionContext.commit(InheritableTransactionContext.java:146) at org.openejb.transaction.ContainerPolicy$TxRequired.invoke(ContainerPolicy.java:152) at org.openejb.transaction.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:80) at org.openejb.SystemExceptionInterceptor.invoke(SystemExceptionInterceptor.java:82) at org.openejb.GenericEJBContainer.invoke(GenericEJBContainer.java:238) at org.openejb.proxy.EJBMethodInterceptor.intercept(EJBMethodInterceptor.java:129) ... 26 more Caused by: org.tranql.ql.QueryException: Error executing statement: INSERT INTO AccountProfileEJB (address, password, userID, email, creditCard, fullName) VALUES (?, ?, ?, ?, ?, ?) at org.tranql.sql.jdbc.JDBCUpdateCommand.execute(JDBCUpdateCommand.java:69) at org.tranql.cache.SimpleFlushStrategy.flush(SimpleFlushStrategy.java:62) at org.tranql.cache.SimpleFlushStrategy.flush(SimpleFlushStrategy.java:49) at org.tranql.cache.cache.InTxCacheTracker.flush(InTxCacheTracker.java:41) at org.tranql.cache.InTxCache.flush(InTxCache.java:86) at org.apache.geronimo.transaction.context.AbstractTransactionContext.flushState(AbstractTransactionContext.java:115) at org.apache.geronimo.transaction.context.InheritableTransactionContext.complete(InheritableTransactionContext.java:175) ... 32 more Caused by: SQL Exception: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'PK_ACCOUNTPROFILE2' defined on 'ACCOUNTPROFILEEJB'. at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.
Re: Petstore with Geronimo M5 ?
Carla Cremers wrote:
[EMAIL PROTECTED]: % diff maven.xml maven.xml.original
26c26
< value="${maven.build.dir}/geronimo-${geronimo_versi
on}"/>
---
> value="${maven.build.dir}/geronimo_${geronimo_versi
on}"/>
Now I get :
[java] Error: Operation failed: Unable to load first parent of
[java] configuration org/apache/geronimo/PetStoreSecurity1.3.2
caused by No configuration with id: org/apache/geronimo/Secure
Any clues ?
Hi Carla,
The changes to make it work are in the repo. I haven't been able to run
PetStore because of some security changes involved which aren't yet
sorted out. Stay tuned.
Please download the latest sources (sandbox/petstore, actually) and give
it a try.
Thanks for the head-up.
Jacek
