• Post Reply Bookmark Topic Watch Topic
  • New Topic

Dropped transactions: socket or thread problem?

 
John O'Donoghue
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have been writing a small banking application just so I could explore SQL and client server programming in java.

Everything went well and the system performs perfectly when I sent one transaction at a time.

However when I wrote a small program to pump transactions at the server from different clients, I started to lose transactions.

I have hunted around for solutions but I am stuck. Any help would be appreciated as when I get over this problem I want to develop
a web interface to the database and then after that a mobile interface from a smart phone.

Anyway I have posted a cut down version of the database handling code called BackEnd.java and the program that pumps a user specified amount of transactions at the back end from the command line ........ e.g. "TestBank3 100" will send 50 transactions of $1 to account numbers 1 and 2.

If I send about 1000 transactions, most of the time none are lost. However send 200000 and then I lose about 10 of them.

I have played around with different values for Thread.sleep() and the ones in the code are the most reliable.



Here is the program that pumps the transactions.

 
Maxim Karvonen
Ranch Hand
Posts: 121
12
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, John.

It's definitely not a socket problem. It is a problem related to threading. I think the root cause is a "non-atomic operation" which leads to a "race condition". You could also google about "lost updates". Lost updates are somewhat SQL-related, but they describes your problem quite well.

Consider the following scenario. Two clients tries to increase balance of account A on 10. Current balance is 3. Consider following sequence of events:


There are possible solutions. You could provide some set of locks to ensure that only one handler could be run at the time for each particular account. You could use JDBC transaction with a proper transaction isolation level (and without autocommit). You could write an "optimistic locking" solution (update balance if its value was not changed otherwise repeat an update code from the start). Or you could change your sql code to increment value instead of fetcing and then updating it. In this case I would prefer the latter approach (change an update statement to "increment value" statement). I could check for "update count" value if I need to perform some actions when update was not performed. For example, I could check if account exists and preconditions are OK to provide better error messages or log possible security issue.
 
John O'Donoghue
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Maxim

Thank you for the reply. It has given me a lot to think about.

Under the heading JDBC Connection Properties in Eclipse, I chose the option of Derby Embedded JDBC Driver. Is that the same as the "JDBC transaction with a proper transaction isolation level" property that you mention?

At present the database is set to the default setting of autocommit so I need to investigate that further.

John

 
Maxim Karvonen
Ranch Hand
Posts: 121
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, John

John O'Donoghue wrote:
Under the heading JDBC Connection Properties in Eclipse, I chose the option of Derby Embedded JDBC Driver. Is that the same as the "JDBC transaction with a proper transaction isolation level" property that you mention?

No, it is not the same. Derby stands for database and its corresponding driver. Transactions and isolation levels are general concepts applicable to all SQL databases.

You configure transaction isolation level through the code. It is part of the standard JDBC API. You could read about isolation levels in Oracle's tutorial here. That page also covers autocommit mode of the Connection.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!