Synchronized implementation of a bank account in Java












3












$begingroup$


I am trying to implement a bank account with Java in a thread safe way. My code looks like:



import java.math.BigDecimal;
import java.math.RoundingMode;
import java.util.concurrent.locks.ReadWriteLock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
* Class to represent an account, it also provides with methods to add and withdraw amount from the account.
*
* @author Karan Khanna
* @version 1.0
* @since 3/17/2019
*/
public class Account {

private ReadWriteLock accountLock;

private BigDecimal balance;

private String accountNumber;

private String accountHolder;

public Account(String accountNumber, String accountHolder) {
this.balance = new BigDecimal(0);
this.accountNumber = accountNumber;
this.accountHolder = accountHolder;
this.accountLock = new ReentrantReadWriteLock();
}

public double getBalance() {
this.accountLock.readLock().lock();
double balance = this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
this.accountLock.readLock().unlock();
return balance;
}

public String getAccountNumber() {
return accountNumber;
}

public String getAccountHolder() {
return accountHolder;
}

public ReadWriteLock getAccountLock() {
return accountLock;
}

public void addAmount(double amount) {
this.accountLock.writeLock().lock();
this.balance.add(new BigDecimal(amount));
this.accountLock.writeLock().unlock();
}

public void withdrawAmount(double amount) {
this.accountLock.writeLock().lock();
this.balance.subtract(new BigDecimal(amount));
this.accountLock.writeLock().unlock();
}
}


I am looking for feedback for the implementation.










share|improve this question









$endgroup$

















    3












    $begingroup$


    I am trying to implement a bank account with Java in a thread safe way. My code looks like:



    import java.math.BigDecimal;
    import java.math.RoundingMode;
    import java.util.concurrent.locks.ReadWriteLock;
    import java.util.concurrent.locks.ReentrantReadWriteLock;

    /**
    * Class to represent an account, it also provides with methods to add and withdraw amount from the account.
    *
    * @author Karan Khanna
    * @version 1.0
    * @since 3/17/2019
    */
    public class Account {

    private ReadWriteLock accountLock;

    private BigDecimal balance;

    private String accountNumber;

    private String accountHolder;

    public Account(String accountNumber, String accountHolder) {
    this.balance = new BigDecimal(0);
    this.accountNumber = accountNumber;
    this.accountHolder = accountHolder;
    this.accountLock = new ReentrantReadWriteLock();
    }

    public double getBalance() {
    this.accountLock.readLock().lock();
    double balance = this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
    this.accountLock.readLock().unlock();
    return balance;
    }

    public String getAccountNumber() {
    return accountNumber;
    }

    public String getAccountHolder() {
    return accountHolder;
    }

    public ReadWriteLock getAccountLock() {
    return accountLock;
    }

    public void addAmount(double amount) {
    this.accountLock.writeLock().lock();
    this.balance.add(new BigDecimal(amount));
    this.accountLock.writeLock().unlock();
    }

    public void withdrawAmount(double amount) {
    this.accountLock.writeLock().lock();
    this.balance.subtract(new BigDecimal(amount));
    this.accountLock.writeLock().unlock();
    }
    }


    I am looking for feedback for the implementation.










    share|improve this question









    $endgroup$















      3












      3








      3





      $begingroup$


      I am trying to implement a bank account with Java in a thread safe way. My code looks like:



      import java.math.BigDecimal;
      import java.math.RoundingMode;
      import java.util.concurrent.locks.ReadWriteLock;
      import java.util.concurrent.locks.ReentrantReadWriteLock;

      /**
      * Class to represent an account, it also provides with methods to add and withdraw amount from the account.
      *
      * @author Karan Khanna
      * @version 1.0
      * @since 3/17/2019
      */
      public class Account {

      private ReadWriteLock accountLock;

      private BigDecimal balance;

      private String accountNumber;

      private String accountHolder;

      public Account(String accountNumber, String accountHolder) {
      this.balance = new BigDecimal(0);
      this.accountNumber = accountNumber;
      this.accountHolder = accountHolder;
      this.accountLock = new ReentrantReadWriteLock();
      }

      public double getBalance() {
      this.accountLock.readLock().lock();
      double balance = this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
      this.accountLock.readLock().unlock();
      return balance;
      }

      public String getAccountNumber() {
      return accountNumber;
      }

      public String getAccountHolder() {
      return accountHolder;
      }

      public ReadWriteLock getAccountLock() {
      return accountLock;
      }

      public void addAmount(double amount) {
      this.accountLock.writeLock().lock();
      this.balance.add(new BigDecimal(amount));
      this.accountLock.writeLock().unlock();
      }

      public void withdrawAmount(double amount) {
      this.accountLock.writeLock().lock();
      this.balance.subtract(new BigDecimal(amount));
      this.accountLock.writeLock().unlock();
      }
      }


      I am looking for feedback for the implementation.










      share|improve this question









      $endgroup$




      I am trying to implement a bank account with Java in a thread safe way. My code looks like:



      import java.math.BigDecimal;
      import java.math.RoundingMode;
      import java.util.concurrent.locks.ReadWriteLock;
      import java.util.concurrent.locks.ReentrantReadWriteLock;

      /**
      * Class to represent an account, it also provides with methods to add and withdraw amount from the account.
      *
      * @author Karan Khanna
      * @version 1.0
      * @since 3/17/2019
      */
      public class Account {

      private ReadWriteLock accountLock;

      private BigDecimal balance;

      private String accountNumber;

      private String accountHolder;

      public Account(String accountNumber, String accountHolder) {
      this.balance = new BigDecimal(0);
      this.accountNumber = accountNumber;
      this.accountHolder = accountHolder;
      this.accountLock = new ReentrantReadWriteLock();
      }

      public double getBalance() {
      this.accountLock.readLock().lock();
      double balance = this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
      this.accountLock.readLock().unlock();
      return balance;
      }

      public String getAccountNumber() {
      return accountNumber;
      }

      public String getAccountHolder() {
      return accountHolder;
      }

      public ReadWriteLock getAccountLock() {
      return accountLock;
      }

      public void addAmount(double amount) {
      this.accountLock.writeLock().lock();
      this.balance.add(new BigDecimal(amount));
      this.accountLock.writeLock().unlock();
      }

      public void withdrawAmount(double amount) {
      this.accountLock.writeLock().lock();
      this.balance.subtract(new BigDecimal(amount));
      this.accountLock.writeLock().unlock();
      }
      }


      I am looking for feedback for the implementation.







      java multithreading thread-safety






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked 5 hours ago









      Karan KhannaKaran Khanna

      1806




      1806






















          1 Answer
          1






          active

          oldest

          votes


















          4












          $begingroup$

          In terms of the basic thread locking, it looks like it is doing the right thing, but there are a number of issues in how you are calculating the account balance, and also some escaped locking as well.



          Note, your post is titled "Synchronized implementation", but it is not, it is a locked implementation. Synchronization is different, and, in this case, it may be a simpler mechanism.



          Locking



          Even if you don't catch exceptions, you should always use the try/finally mechanism for locking. Here, for example, it's possible that the addition may throw an exception (even though you don't catch it):



          public void addAmount(double amount) {
          this.accountLock.writeLock().lock();
          try {
          this.balance.add(new BigDecimal(amount));
          } finally {
          this.accountLock.writeLock().unlock();
          }
          }


          In case you think that's extreme, well, the amount could be NaN or infinity, and that would throw a NumberFormatException, etc. Even if it were impossible for the logic to throw an error, you should still use the try/finally mechanism because it makes the logic obvious.



          The balance method has the most to gain:



          public double getBalance() {
          this.accountLock.readLock().lock();
          try {
          return this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
          } finally {
          this.accountLock.readLock().unlock();
          }
          }


          You are also leaking the lock through the public method to get it. You really should not allow other people to manipulate the lock strategy you have in your class. It is intended to be internal for a reason.



          Speaking of that lock, you should also make it final...



          private final ReadWriteLock accountLock;


          Bugs



          The most glaring issue is not with your locking, but with the balance management itself. BigDecimals are immutable. They cannot be changed. This does nothing: this.balance.add(new BigDecimal(amount)); .... that should be this.balance = this.balance.add(new BigDecimal(amount));.



          The accountNumber and accountHolder should be final as well.



          Finally, the getBalance method will not always return a 2-decimal double value. Not all values in binary floating-point are representable in decimal.






          share|improve this answer











          $endgroup$













            Your Answer





            StackExchange.ifUsing("editor", function () {
            return StackExchange.using("mathjaxEditing", function () {
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
            });
            });
            }, "mathjax-editing");

            StackExchange.ifUsing("editor", function () {
            StackExchange.using("externalEditor", function () {
            StackExchange.using("snippets", function () {
            StackExchange.snippets.init();
            });
            });
            }, "code-snippets");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "196"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f215616%2fsynchronized-implementation-of-a-bank-account-in-java%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4












            $begingroup$

            In terms of the basic thread locking, it looks like it is doing the right thing, but there are a number of issues in how you are calculating the account balance, and also some escaped locking as well.



            Note, your post is titled "Synchronized implementation", but it is not, it is a locked implementation. Synchronization is different, and, in this case, it may be a simpler mechanism.



            Locking



            Even if you don't catch exceptions, you should always use the try/finally mechanism for locking. Here, for example, it's possible that the addition may throw an exception (even though you don't catch it):



            public void addAmount(double amount) {
            this.accountLock.writeLock().lock();
            try {
            this.balance.add(new BigDecimal(amount));
            } finally {
            this.accountLock.writeLock().unlock();
            }
            }


            In case you think that's extreme, well, the amount could be NaN or infinity, and that would throw a NumberFormatException, etc. Even if it were impossible for the logic to throw an error, you should still use the try/finally mechanism because it makes the logic obvious.



            The balance method has the most to gain:



            public double getBalance() {
            this.accountLock.readLock().lock();
            try {
            return this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
            } finally {
            this.accountLock.readLock().unlock();
            }
            }


            You are also leaking the lock through the public method to get it. You really should not allow other people to manipulate the lock strategy you have in your class. It is intended to be internal for a reason.



            Speaking of that lock, you should also make it final...



            private final ReadWriteLock accountLock;


            Bugs



            The most glaring issue is not with your locking, but with the balance management itself. BigDecimals are immutable. They cannot be changed. This does nothing: this.balance.add(new BigDecimal(amount)); .... that should be this.balance = this.balance.add(new BigDecimal(amount));.



            The accountNumber and accountHolder should be final as well.



            Finally, the getBalance method will not always return a 2-decimal double value. Not all values in binary floating-point are representable in decimal.






            share|improve this answer











            $endgroup$


















              4












              $begingroup$

              In terms of the basic thread locking, it looks like it is doing the right thing, but there are a number of issues in how you are calculating the account balance, and also some escaped locking as well.



              Note, your post is titled "Synchronized implementation", but it is not, it is a locked implementation. Synchronization is different, and, in this case, it may be a simpler mechanism.



              Locking



              Even if you don't catch exceptions, you should always use the try/finally mechanism for locking. Here, for example, it's possible that the addition may throw an exception (even though you don't catch it):



              public void addAmount(double amount) {
              this.accountLock.writeLock().lock();
              try {
              this.balance.add(new BigDecimal(amount));
              } finally {
              this.accountLock.writeLock().unlock();
              }
              }


              In case you think that's extreme, well, the amount could be NaN or infinity, and that would throw a NumberFormatException, etc. Even if it were impossible for the logic to throw an error, you should still use the try/finally mechanism because it makes the logic obvious.



              The balance method has the most to gain:



              public double getBalance() {
              this.accountLock.readLock().lock();
              try {
              return this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
              } finally {
              this.accountLock.readLock().unlock();
              }
              }


              You are also leaking the lock through the public method to get it. You really should not allow other people to manipulate the lock strategy you have in your class. It is intended to be internal for a reason.



              Speaking of that lock, you should also make it final...



              private final ReadWriteLock accountLock;


              Bugs



              The most glaring issue is not with your locking, but with the balance management itself. BigDecimals are immutable. They cannot be changed. This does nothing: this.balance.add(new BigDecimal(amount)); .... that should be this.balance = this.balance.add(new BigDecimal(amount));.



              The accountNumber and accountHolder should be final as well.



              Finally, the getBalance method will not always return a 2-decimal double value. Not all values in binary floating-point are representable in decimal.






              share|improve this answer











              $endgroup$
















                4












                4








                4





                $begingroup$

                In terms of the basic thread locking, it looks like it is doing the right thing, but there are a number of issues in how you are calculating the account balance, and also some escaped locking as well.



                Note, your post is titled "Synchronized implementation", but it is not, it is a locked implementation. Synchronization is different, and, in this case, it may be a simpler mechanism.



                Locking



                Even if you don't catch exceptions, you should always use the try/finally mechanism for locking. Here, for example, it's possible that the addition may throw an exception (even though you don't catch it):



                public void addAmount(double amount) {
                this.accountLock.writeLock().lock();
                try {
                this.balance.add(new BigDecimal(amount));
                } finally {
                this.accountLock.writeLock().unlock();
                }
                }


                In case you think that's extreme, well, the amount could be NaN or infinity, and that would throw a NumberFormatException, etc. Even if it were impossible for the logic to throw an error, you should still use the try/finally mechanism because it makes the logic obvious.



                The balance method has the most to gain:



                public double getBalance() {
                this.accountLock.readLock().lock();
                try {
                return this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
                } finally {
                this.accountLock.readLock().unlock();
                }
                }


                You are also leaking the lock through the public method to get it. You really should not allow other people to manipulate the lock strategy you have in your class. It is intended to be internal for a reason.



                Speaking of that lock, you should also make it final...



                private final ReadWriteLock accountLock;


                Bugs



                The most glaring issue is not with your locking, but with the balance management itself. BigDecimals are immutable. They cannot be changed. This does nothing: this.balance.add(new BigDecimal(amount)); .... that should be this.balance = this.balance.add(new BigDecimal(amount));.



                The accountNumber and accountHolder should be final as well.



                Finally, the getBalance method will not always return a 2-decimal double value. Not all values in binary floating-point are representable in decimal.






                share|improve this answer











                $endgroup$



                In terms of the basic thread locking, it looks like it is doing the right thing, but there are a number of issues in how you are calculating the account balance, and also some escaped locking as well.



                Note, your post is titled "Synchronized implementation", but it is not, it is a locked implementation. Synchronization is different, and, in this case, it may be a simpler mechanism.



                Locking



                Even if you don't catch exceptions, you should always use the try/finally mechanism for locking. Here, for example, it's possible that the addition may throw an exception (even though you don't catch it):



                public void addAmount(double amount) {
                this.accountLock.writeLock().lock();
                try {
                this.balance.add(new BigDecimal(amount));
                } finally {
                this.accountLock.writeLock().unlock();
                }
                }


                In case you think that's extreme, well, the amount could be NaN or infinity, and that would throw a NumberFormatException, etc. Even if it were impossible for the logic to throw an error, you should still use the try/finally mechanism because it makes the logic obvious.



                The balance method has the most to gain:



                public double getBalance() {
                this.accountLock.readLock().lock();
                try {
                return this.balance.setScale(2, RoundingMode.HALF_DOWN).doubleValue();
                } finally {
                this.accountLock.readLock().unlock();
                }
                }


                You are also leaking the lock through the public method to get it. You really should not allow other people to manipulate the lock strategy you have in your class. It is intended to be internal for a reason.



                Speaking of that lock, you should also make it final...



                private final ReadWriteLock accountLock;


                Bugs



                The most glaring issue is not with your locking, but with the balance management itself. BigDecimals are immutable. They cannot be changed. This does nothing: this.balance.add(new BigDecimal(amount)); .... that should be this.balance = this.balance.add(new BigDecimal(amount));.



                The accountNumber and accountHolder should be final as well.



                Finally, the getBalance method will not always return a 2-decimal double value. Not all values in binary floating-point are representable in decimal.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited 5 hours ago

























                answered 5 hours ago









                rolflrolfl

                91.1k13192395




                91.1k13192395






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Code Review Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    Use MathJax to format equations. MathJax reference.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f215616%2fsynchronized-implementation-of-a-bank-account-in-java%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Wolfgang Unzicker

                    Unua mondmilito

                    Schloss Hohenburg (Lenggries)