I am trying to reproduce (and not fullproof test the multithreading issue) the thread block issue in one of my methods by writing a unit test. Since I see plenty of instances of
org.hibernate.exception.LockAcquisitionException: could not execute update query
in our 2 server PROD environment, I should be able to reproduce fairly easily in my unit test.
I tried to spawn multiple threads within my JUnit method and each thread invoking my method. I tried with 2 threads to begin with.
ExecutorService exec = Executors.newFixedThreadPool(16);
for (int i = 0; i < 2; i++) {
exec.execute(new Runnable() {
public void run() {
System.out.println("who is running: " + Thread.currentThread().getId());
em.getTransaction().begin();
//do something()
em.getTransaction().commit();
}
});
}
I get an error:
Exception in thread "pool-1-thread-2" who is running: 11
java.lang.IllegalStateException: Transaction already active
at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:35)
It is not letting me create Transaction for the second thread with an error 'Transaction is already Active'. I thought EntityManager could have multiple Active Threads present at any given time ( and hence a singleton entitymanager)?
Am I missing something here?
Thanks
EntityManager is not thread-safe. That's why it is often told that you should not inject EntityManager to shared instances like Servlets. It is clearly documented (JSR-317 page 286):
An entity manager must not be shared among multiple concurrently
executing threads, as the entity manager and persistence context are
not required to be threadsafe. Entity managers must only be accessed
in a single-threaded manner.
Related
I am working on a small microfinance application that processes financial transactions, the frequency of these transaction are quite high, which is why I am planning to make it a multi-threaded application that can process multiple transactions in parallel.
I have already designed all the workers that are thread safe,
what I need help for is how to manage these threads. here are some of my options
1.make a specified number of thread pool threads at startup and keep them running like in a infinite loop where they could keep looking for new transactions and if any are found start processing
example code:
void Start_Job(){
for (int l_ThreadId = 0; l_ThreadId < PaymentNoOfWorkerThread; l_ThreadId++)
{
ThreadPool.QueueUserWorkItem(Execute, (object)l_TrackingId);
}
}
void Execute(object l_TrackingId)
{
while(true)
{
var new_txns = Get_New_Txns(); //get new txns if any returns a queue
while(new_txns.count > 0 ){
process_txn(new_txns.Dequeue())
}
Thread.Sleep(some_time);
}
}
2.look for new transactions and assign a thread pool thread for each transaction (my understanding that these threads would be reused after their execution is complete for new txns)
example code:
void Start_Job(){
while(true){
var new_txns = Get_New_Txns(); //get new txns if any returns a queue
for (int l_ThreadId = 0; l_ThreadId < new_txns.count; l_ThreadId++)
{
ThreadPool.QueueUserWorkItem(Execute, (object)new_txn.Dequeue());
}
}
Thread.Sleep(some_time);
}
void Execute(object Txn)
{
process_txn(txn);
}
3.do the above but with tasks.
which option would be most efficient and well suited for my application,
thanks in advance :)
ThreadPool.QueueUserWorkItem is an older API and you shouldn't be using it directly
anymore. Tasks is the way to go and Thread pool is managed automatically for you.
What may suite your application would depend on what happens in process_txn and is subjective, so this is very generic guideline:
If process_txn is a compute bound operation: for example it performs only CPU bound calculations, then you may look at the Task Parallel Library. It will help you use the CPU cores more efficiently.
If process_txn is less of CPU and more IO bound operations: meaning if it may read/write from files/database or connects to some other remote service, then what you should look at is asynchronous programming and make sure your IO operations are all asynchronous which means your threads are never blocked on IO. This will help your service to be more scalable. Also depending on what your queue is, see if you can await on the queue asynchronously, so that none of your application threads are blocked just waiting on the queue.
I am using grpc-java and have 3 services, A, B and C. I call service A and then service A calls B and C. I am using Hystrix in the calls to B and C. C in turn spawns another thread to call another service.
I have ClientInterceptors and ServerInterceptors which passes around the traceId. I can see the traceIds in the Context and logs as long as it is a gRPC worker thread but lose them when the call moves to another thread - RxIoScheduler thread or Hystrix thread. How do I pass the traceId around between requests on different threads and between different executor service and thread pools?
While it is possible to propagate in a fine-grained way (like executor.execute(Context.current().wrap(runnable))), you should try to integrate Context propagation into cross-thread work transfer. For many applications, that'd be as simple as wrapping the "main" executor as soon as it is created:
executor = Context.currentContextExecutor(executor);
// executor now auto-propagates
Do that once at the beginning of your application and then you mostly stop worrying about propagation.
But applications will vary. For example, applications that create Threads directly should probably make a ThreadFactory that propagates the calling thread's Context to the Thread:
class PropagatingThreadFactory implements ThreadFactory {
private final ThreadFactory delegate;
public PropagatingThreadFactory(ThreadFactory d) {delegate = d;}
#Override public Thread newThread(Runnable r) {
return delegate.newThread(Context.current().wrap(r));
}
}
After reading and watching some videos on dependency injection I still don't understand how to use it properly without breaking encapsulation.
Note: I read How to use Dependency Injection without breaking encapsulation? but I'm still not 100% sure.
My code is a very simple implementation of thread pool, which contains objects of class Worker which is a package-private class that I don't want to expose to the outside world (and it's really non of their concern).
My thread pool constructor requires a parameter Worker[] workers (I don't need a factory since I know in advance exactly how many workers I need).
Since my Worker class is package-private I thought that the right way to construct the thread factory would be to implement a static factory method in the ThreadPool class as follows:
public static ThreadPool createThreadPool(int numOfWorkers,
BlockingQueue<Runnable> jobQueue,
ThreadFactory threadFactory) {
Worker workers[] = new Worker[numOfWorkers];
for (int i = 0; i < workers.length; i++) {
workers[i] = new Worker(jobQueue, threadFactory, i);
// worker needs the factory in order to provide itself as Runnable
}
return new ThreadPool(workers, jobQueue);
}
So, is creating all these new objects in the static factory method the right way to hide the Worker class from other packages, or is there something I'm missing here?
Dependency Injection would mean hiding the creation of the Workers from the ThreadPool. Ideally, Runnables should be passed into the ThreadPool constructor, and the ThreadPool shouldn't even know that the Runnables happen to be Workers.
Creation of the Workers should occur in the composition root.
I have a situation where I need a set of operations be enclosed into a single transaction and be thread safe from a MDB.
If thread A executes the instruction 1, do not want other threads can read, at least not the same, data that thread A is processing.
In the code below since IMAGE table contains duplicated data, coming from different sources, this will lead in a duplicated INFRANCTION. Situation that needs to be avoided.
The actual solution that I found is declaring a new transaction for each new message and synchronize the entire transaction.
Simplifying the code:
#Stateless
InfranctionBean{
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
checkInfranction(String plate){
1. imageBean.getImage(plate); // read from table IMAGE
2. infranctionBean.insertInfranction(String plate); // insert into table INFRANCTION
3. imageBean.deleteImage(String plate); //delete from table IMAGE
}
}
#MessageDriven
public class ImageReceiver {
private static Object lock = new Object();
public void onMessage(Message msg){
String plate = msg.plate;
synchronized (lock) {
infanctionBean.checkInfranction(plate);
}
}
}
I am aware that using synchronized blocks inside the EJB is not recommanded by EJB specification. This can lead even in problems if the applicaton server runs in two node cluster.
Seems like EE6 has introduced a solution for this scenario, which is the EJB Singleton.
In this case, my solution would be something like this:
#ConcurrencyManagement(ConcurrencyManagementType.CONTAINER)
#Singleton
InfranctionBean{
#Lock(LockType.WRITE)
checkInfranction(String plate){
1...
2...
3...
}
}
And from MDB would not be neccessary the usage of synchronized block since the container will handle the concurrency.
With #Lock(WRITE) the container guarantees the access of single thread inside checkInfranction().
My queston is: How can I handle this situation in EE5? There is a cleaner solution without using synchronized block?
Environment: Java5,jboss-4.2.3.GA,Oracle10.
ACTUAL SOLUTION
#Stateless
InfranctionBean{
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
checkInfranction(String plate){
1. imageBean.lockImageTable(); // lock table IMAGE in exclusive mode
2. imageBean.getImage(plate); // read from table IMAGE
3. infranctionBean.insertInfranction(String plate); // insert into table INFRANCTION
4. imageBean.deleteImage(String plate); //delete from table IMAGE
}
}
#MessageDriven
public class ImageReceiver {
public void onMessage(Message msg){
infanctionBean.checkInfranction(msg.plate);
}
}
On 20.000 incoming messages (half of them simultaneously) seems the application works ok.
#Lock(WRITE) is only a lock within a single application/JVM, so unless you can guarantee that only one application/JVM is accessing the data, you're not getting much protection anyway. If you're only looking for single application/JVM protection, the best solution in EE 5 would be a ReadWriteLock or perhaps a synchronized block. (The EJB specification has language to dissuade applications from doing this to avoid compromising the thread management of the server, so take care that you don't block indefinitely, that you don't ignore interrupts, etc.)
If you're looking for a more robust cross-application/JVM solution, I would use database locks or isolation levels rather than trying to rely on JVM synchronized primitives. That is probably the best solution regardless of the EJB version being used.
I am facing issue in multi threading .
Case : I am creating exe to download photos from some another website , As there are 1000's of photos coming from other server i have implemented multi-threading, but that is not working properly
In Main() , i have called a method named as ThreadMain();
and In ThreadMain(); function, we have divided task into ten threads like
ThreadStart jobOne = new ThreadStart(ThreadOne);
Thread threadOne = new Thread(jobOne);
// Start the thread
threadOne.Start();
ThreadStart jobTwo = new ThreadStart(ThreadTwo);
Thread threadTwo = new Thread(jobTwo);
threadTwo.Start();
ThreadStart jobThree = new ThreadStart(ThreadThree);
Thread threadThree = new Thread(jobThree);
threadThree.Start();
etc upto 10 threads
Then further we have defined static method like
static void ThreadOne()
{
database tasks
}
static void ThreadTwo()
{
database tasks
}
static void ThreadThree()
{
database tasks
}
Upto 10 jobs
But After completing threads,console window does not close itself Or i am not able to know whether threads are completed or NOT ? Please advice
use background workers.
They are a special kind of thread which runs in your program. You can use the "Progress" property of the background worker to report the progress to another method and in the method compute the necessary criteria and check if the threads are closed and finally close the program.
If you do not want to alter the structure of the program another method would be to have another thread called "watcherThread" (call it wat ever u want) and make this thread run continuosly in intervals of three or five seconds based upon your general execution time and have it check the isRunning property of all the other threads or threadState property of all the other threads and once you know all threads have completely run you can safely close your windows using "environment.exit(0);"
Some references
http://msdn.microsoft.com/en-us/library/cc221403(v=vs.95).aspx
http://www.dotnetperls.com/backgroundworker
http://midnightprogrammer.net/post/Using-Background-Worker-in-C.aspx
http://csharptuning.blogspot.com/2007/05/background-worker.html