Transaction processor is a part of switch which is used for banking job.(shown in picture below) ![alt text][1]
which aspects of this part should be considered in designing? I mean concurrency needs.for example for threads. when a new thread should be created for answering a request and when have to be deleted?how can I reduce overhead of managing threads? and when synchronization is needed for data? does anyone has idea about it?
Create the threads at the beginning (one set for creating the tasks, the other set for handling them), when the application starts. Then, use the Producer-Consumer pattern. It looks appropriate for your case.
Sounds like a typical case of producer/consumer pattern where your Message handler does the producing and the Transaction Processor does the consuming. Depending on the relative difficulty (in processing time) of Message handling / Transaction processing either of these, or both could use a thread pool rather than a single thread to do their handling/processing.
The first order of reducing the overhead of managing threads is to use a class that does it for you. (i.e. any of the thread pools)
Regarding synchronisation, if you do use a single queue between Message Handler and Transaction Processor and both are in their own thread (or thread pool) then you need to synchronise access to that queue. Use any of the implementations of the BlockingQueue from java.util.concurrent for that.
Producer consumer is old school, and is not a silver bullet. The Actor model is considered the silver bullet these days. It is used by Erlang.
If you solve your homework using the actor model, or providing a discussion of said model you should get a high grade :D
p.s., there are many workloads where the actor pattern does not apply, such as embedded programming / operating system kernels / video game engines. The Actor works really well for large scale client - server projects which covers a lot of the business programming these days.
p.s.s To confuse you further (and to give you more to discuss): the actor pattern is usually implemented on-top of a producer-consumer inspired engine :P
In banking systems atomicity of operations are a vital feature. Either the financial transaction finishes completely, or it doesn't happen at all. Money doesn't get dropped on the floor just because some part of the operation fails.
This means transactional integrity is the most vital quality. This is typically solved either by using a distributed transaction coordinator (XA) and two-phase commit, or by using reversible subtransactions for rollback.