Write Java program follow the file's instruction and please commend on each code section about what's going on
Final Programming Assignments … Threads, Locking, and Replication This final assignment, assigned early, is really a three-part assignment dealing with the inner workings of any database manager system. It is being assigned early, and in parallel with more typical periodic assignments to allow you the time needed for its successful completion. As a multi-part assignment, the earlier part(s) will need to be completed successfully to also be successful on subsequent parts. So, what is it? It is an emulation of the internal workings of any database manager system in the way it supports · An internalized database structure holding in memory the contents of the database, · Over which multi-step transactions are executed, potentially rolled back, and recovered, · Locking over the concurrently changing data in that structure, · High availability via data replication to another database management system, · Logging of transactions for reasons of rolling back transactions, and, of course, · Multi-Threading to enable concurrent access to the database, · Ultimately producing a persistent version of the internalized database structure in a file. So, first, the bigger picture. Picture three complete systems: 1. A Primary DBMS, one holding and managing a database of an arbitrary number of bank accounts. 2. An application system running a bank teller application (all in support of a bank teller web page not considered here), with its user interface used by an arbitrary number of bank tellers. 3. A Replicate (Backup) DBMS, also holding a copy of the database of bank accounts, maintaining it in a way that is synchronous with transactions being processed by the Primary DBMS. [In the real world, this really would be a set of separate systems communicating using TCP/IP. Here, though, this entire environment runs on your laptop and all within one program. To do so, sets of threads with each set executing the code associated with each role will be messaging as an emulation of those separate systems.] Although what we will be building here is not a perfect metaphor, since it is all running on one system, one program using threads, and all using shared memory, think in terms of 1. Multiple bank tellers are each requesting multiple account transfers within a single transaction and are repeatedly creating such transactions. The bank tellers are not aware of each other. These account transfer request messages – and the fact that sets of these are part of a single transaction – are sent from the Application system to only the Primary DBMS system for processing. Think in terms of sending SQL-like Update messages, but these command strings will be using a different syntax and have a bit different meaning as you will see shortly. 2. Just as with Java/JDBC applications on the Application server, each command message will be sent to the Primary DBMS. Our commands will only be Update-like operations, so we will dispense with the need for a response on each Update from the DBMS to the application (i.e., no Result Set returned on an update). 3. The DBMS, seeing these request messages as steps of a transaction, executes the operation given the usual rules of a transaction. These account-transfer change requests alter the bank account data repository, first on the Primary DBMS. In order to allow for maximum throughput and concurrency, the DBMS will have multiple threads waiting to concurrently service these requests. 4. Only upon completing the transaction – flagged via an incoming commit request – will the Primary DBMS respond back to the bank teller application that the transaction is complete. You can think of that application as then responding back to the teller’s web page that the account transfers have succeeded, and only success is expected. Upon receipt of a successful commit, the teller immediately requests the next similar transaction. 5. However, prior to this perception of a completed commit, the synchronous Replicate DBMS must have been aware of – and perhaps completely processed – that entire transaction. The Replicate DBMS responds back to the Primary DBMS after receipt and execution of that transaction request (and all of its steps) on that replicate system. Again, this is the mental model for this assignment. Of course, this will not be run on multiple systems and indeed will be run within a single application. Rather than separate threads running within different programs on three systems, we will have sets of threads representing each of these component systems, all communicating via Java objects in shared memory. As mentioned above, the teller never sees a failed transaction, but internal failures do occur due to threading deadlocks. As with all transactions, a failure in any part of a transaction means that the transaction is rolled back and here will be transparently and internally restarted. Only when a transaction has been completed successfully will the teller be told of its completion. From each single teller’s point of view, there is only one transaction executed at a time, after which that one teller starts another similar transaction. Always keep in mind that there are multiple such tellers so transactions will often be concurrently executing. I do want to have your emulation force deadlocks. To occasionally produce temporary deadlock conditions, this simulated bank will have only 100 accounts. [However, your implementation may not assume that nor any order since tellers can normally add and delete accounts.] Each account will have a unique account number, customer names (first and last), and initially an equal amount of money in each account. The source for this information will be found in a file named Accounts.txt; the first two columns can be treated as the first and last names, the third the account numbers, and the last the amounts in each account. Another such file, to be described shortly, which this program will be creating, will be used to represent the persistent state of the current accounts after transactions are executed; there will be one such for each of both the Primary and Replicate DBMSs. The file Accounts.txt is used only to load an internal memory-based data repository, an internal representation of a database. Again to create temporary deadlock conditions, the date repositories data structure will be based on a 20-entry hash table (with hash function based upon the account number) with each hash table entry there anchoring a Java LinkedList of Account objects. Each hash table entry will ensure consistent updates of its accounts by also supporting a lock over that entry’s LinkedList; as such there are also 20 locks. (Do not assume that account transfers are limited to accounts under a single hash table entry.) Please be aware, however, that the tellers are only aware of the account numbers, not the actual content of the database. [Please do not use Java HashTable or HashMap objects for supporting this. That will only confuse you. Again, you want a lock object associated with each LinkedList
.] On the Primary system (as opposed to the Replicate system), incoming transaction requests will be concurrently executed within your DBMS by way of multiple threads. This could be any number of threads within the DBMS – so design for any – but your instructor suspects that four will be sufficient. From the bank teller application’s point of view, each is throwing individual transaction request strings to single DBMS. To do so a couple approaches can be used (your choice): · One is similar to a connection-based TCP/IP socket’s approach where a teller thread is communicating one-to-one with a corresponding DBMS thread. Here communication occurs using a pair of queues, a request queue for incoming messages to the DBMS and a response queue for responses from the DBMS. · The other is based on a connection-less socket’s approach where all the teller threads send in their requests to a single queue, a queue monitored by all of the DBMS threads. Transaction consistency and concurrency is handled by ensuring that all of the requests associated with a given transaction are only ever processed by a single DBMS thread. (You will see shortly that we will have the tellers identify themselves via a unique transaction ID in this emulation.) Responses from the DBMS are here via a response queue per teller thread. As mentioned above, each transaction request is an independent set of emulated database operations, here of only three types. In all the following, “id” is a unique transaction number, a number generated here as an atomic counter by the teller threads. · … Indicating the beginning of a transaction, · … Each actual account transfer, randomly from 1 to 5 updates per transaction. · … Indicating the end of the transaction and the need to commit results. The UPDATE operation – a string - includes additional information producing a message as in the following: Source Account #, Target Account #, Transfer Amount with the transfer amount being interpretable as dollars and cents. The messages sent from the teller to your DBMS must be in this form. Within each such update the account numbers are randomly chosen by the teller from the available account numbers; the source and target amounts must be different. The transfer amount is a random value less than $1000. The number of updates per transaction is a random number up to 5. [The Log.txt file containing these is provided for demonstration purposes.] Clearly enough, the transfer amount is subtracted from the source account and added to the target account. The response message from the DBMS back to the “teller” after a successful transaction reads . Recall that this is to allow the beginning of a next transaction to be subsequently created and sent down to the DBMS. The “tellers” - perhaps threads in their own right, perhaps your Initial thread, your choice – will each send at least 100 full transaction requests. Upon completion of the last transaction the program ends with all threads ending cleanly. No thread may remain an orphan. [Contact your instructor for possible approaches – there are many – if you prefer.] Both request message queue(s) and response queue(s) are simply LinkedList’s of Strings as in LinkedList. As mentioned above, think of each String as being no different than a single SQL-like operation being sent to the DBMS; each string is not the entire transaction. Keep in mind that the teller has no idea when the DBMS thread(s) accept and process each of these individual messages. Clearly from the format of the , each such request will update