What happens when I have a number of active JDBC transactions and a redeploy hits the web application?, I searched the Tomcat docs but didn't find anything related.
For example: 30 customers have a shopping cart with items and they save the order at the same time, so a transaction is started, and a redeploy is triggered
What happens? Do the all items get correctly saved? or At time of redeploy all active transactions are discarded? or Tomcat waits the redeploy command till all the transactions are commited?
I'm using Tomcat JDBC Pool
The key point to keep in mind is where is the connection pool instantiated?
If you define the connection pool at the Context level, then the connection pool is created when the context is created, and should be destroyed with the context too.
Redeploying an application in Tomcat requires shutting down the current context and then starting up the replacement context. So in that case I would expect that the behaviour will be determined by the value of defaultAutCommit or the effective value of autoCommit for each transaction. If true then shutting down the resource should commit the transactions. If false then, just like with any InterruptedException your exception handling path should trigger rollback, or worst case the connection shutdown should rollback the transaction.
What you really want to examine is how Tomcat shuts down an application. I have not looked at the actual code in detail, but my understanding is that first it stops sending requests to the "old context". Then once all the pending responses have completed, the ServletContextListeners get called to notify of shutdown, once they and their Filter and Servlet counterparts are completed, the context is effectively shut down and the resources can be cleaned up. What complicates things, IIRC is that Tomcat does not wait for ever for responses to complete and may start interrupting the handler treads, or just plain switch over to the new context without waiting for the old or to finish tearring down.
I annot remember which container (jetty/tomcat) supports starting up the new context and then switching request handling over only once the new context is ready to give zero downtime switch over... The key issue with that is you need a persistent session store and an applcation that can run on a cluster safely to be able to use such a deployment mode.
In short, your applcation will be shutdown gracefully before the new context starts, so I would expect transactions to either complete or recipe an InterruptedException at which point your try...finally blocks should kick in
Related
Consider that I'm not using the Production Server for a week. What will happen to the Spring Beans that are created? Do they stay in the memory ? or Do they have a idle timeout to call its destroy and close the application context till the next request?
Spring beans are created at application startup and will stay in memory, until the application is stopped.
The same is true for the application context that contains all these beans, it will also stay in memory.
If the application context would be closed, there would be nothing to process the next request.
As Alex.R commented, beans may have other scopes like 'request' or 'session', but that is a different story.
Considering it as Singleton, after 1 week too the beans stays in memory right ?
Exactly. Spring does not destroy singleton beans on its own.
I was running some demo spring apps on Amazon, which sometimes had no traffic for month and they never shut down from alone.
I'm trying to implement the failover strategy when executing jbpm6 processes. My setup is the following:
I'm using jbpm6.2.0-Final (latest stable release) with persistence enabled
I'm constructing an instance of org.kie.spring.factorybeans.RuntimeManagerFactoryBean with type SINGLETON to get KSession to start/abort processes and complete/abort work items
all beans are wired by Spring 3.2
DB2 is used a database engine
I use Tomcat 7.0.27
In the positive scenario everything is working as I expect. But I would like to know how to resume the process in the case of server crash. To reproduce it I started my process (described as BPMN2 file), got at some middle step and killed the Tomcat process. After that I see uncompleted process instance in the PROCESS_INSTANCE_INFO table and uncompleted work item in the WORK_ITEM_INFO table. Also there is a session in the SESSION_INFO table.
My question is: could you show me the example of code which would take that remaining process and resume it starting from the last node (if it is possible).
Update
I forgot to mention that i'm not using jbpm-console, but I'm embedding jbpm into my javaee application.
If you initialize your RuntimeManager on init of your application Server it should take care of reloading and resuming the processes.
You need not worry about reloading it again by yourself.
My question is about this answer here that seems to work for my case (tomcat). However I see that it uses a newSingleThreadScheduledExecutor(). In my case the periodical task that has to be executed could be long lasting and I want to make sure that it will not block my web site until it has completed (run as a separated Thread). In addition I want to make sure that my task Runnable will be able to share mySQL connection pool (through hibernate) that the web site is using.
So, is that still the correct approach or do I have to use something else?
I want to make sure that it will not block my web site until it has
completed (run as a separated Thread)
The HTTP connector thread pool and the thread pool allocated to run timer tasks are different. They are not dependent on each other and will not block your website.
In addition I want to make sure that my task Runnable will be able to
share mySQL connection pool (through hibernate) that the web site is
using. So, is that still the correct approach or do I have to use
something else?
Configure a common connection pool using a framework like commons DBCP and lookup the resource on the JNDI. Once you lookup that DataSource and the work on the connection has terminated, return the connection back to the pool.
The approach is fine.
We are using JTA to manage global transactions in servlet context. Additionally, some of the servlet threads are invoking asynchronous beans. Currently, I have designed it in a way so that the asynchronous bean (Work Manager) gets its own transaction.
It's my understanding that two threads can participate in the same XA transaction. But if I start using the transaction created by the servlet, for the asynchronous bean, will that block the servlet thread until all participant have committed or rolled back? Both the servlet and the async bean can commit and rollback.
The app server is WebSphere, and we are NOT using Spring.
Your response is appreciated.
Using the same transaction both for the servlet thread and an asynchronous worker conflicts somehow with the general idea of messaging. Messaging is a means to decouple, whereas a transaction keeps things tightly together.
In other words, if you want a worker to use the same transaction, I would not implement the worker in an asynchronous way.
As for two threads participating in the same XA transaction, this might not be supported, look here for details. Even if it worked, it could be troublesome to share resources over a thread context generally speaking (file handles, connections, transactions whatever).
As for the servlet thread, whether it blocks: I have never tried it (for the above reasons), but I assume that it does not block: You would have to wait/poll for your async workers, until they have finished (or failed). Otherwise the servlet just reaches your commit statement.
I have a Tomcat servlet that incorporates hibernate. It works fine normally. When the servlet starts I initialize hibernate and create a session factory. I then use this session factory to generate sessions when performing various database transactions. So far so good. My problem comes after a long period of inactivity on the servlet (say when the users go home for the night and then try to log in the next morning). Suddenly, I am unable to communicate with the databse. In the logs I see
org.hibernate.exception.JDBCConectionException: Could not execute query.
If I stop and restart Tomcat, reinitializing my servlet and rebuilding my session factory, everything works fine. It is almost like the session factory itself is timing out?
Any ideas?
Thanks,
Elliott
If I stop and restart Tomcat, reinitializing my servlet and rebuilding my session factory, everything works fine. It is almost like the session factory itself is timing out?
It's not the session factory but the connections used by the session factory (e.g. MySQL is well known to timeout connections after 8 hours of inactivity by default). Either:
use a connection pool that is able to validate connections on borrow and to renew them ~or~
increase the idle timeout on the database side
OK. Suppose I use a c3P0 connection pool. How do I specify in the hibernate.cfg.xml file that I want to "validate connections on borrow" or does it do this by default?
The various options when using C3P0 are documented in Configuring Connection Testing. My advice would be to use the idleConnectionTestPeriod parameter:
The most reliable time to test
Connections is on check-out. But this
is also the most costly choice from a
client-performance perspective. Most
applications should work quite
reliably using a combination of
idleConnectionTestPeriod and
testConnectionsOnCheckIn. Both the
idle test and the check-in test are
performed asynchronously, which leads
to better performance, both perceived
and actual.
Note that for many applications, high
performance is more important than the
risk of an occasional database
exception. In its default
configuration, c3p0 does no Connection
testing at all. Setting a fairly long
idleConnectionTestPeriod, and not
testing on checkout and check-in at
all is an excellent, high-performance
approach.
To configure C3P0 with Hibernate, be sure to read the relevant instructions (and to use the appropriate properties, and the appropriate files).