RE: JPA required?
For your use case, probably not. JPA is not something that is going to solve a database element corruption and in fact with JPA and its normal use, you have less control when entity changes are flushed to the database. Note that if you don't have your database stored on medium that has write caching, if the host computer goes down, the database is not going to be corrupt; it might not have the latest change, but it will be consistent if you are using transactions. -Original Message- From: JimCrowell37 [mailto:jimcrow...@email.com] Sent: Tuesday, February 12, 2013 4:52 PM To: derby-user@db.apache.org Subject: JPA required? Hello, I have spent today reading up on JPA and I have a question if I really need it. I have a data entry form class where each data entry field is associated with an element of a Derby dynamic database table. As each data entry field looses it's form focus, I shall write the entered data entry value to the Database table. The Database table primary key is the fields row / column indices. Since my goal is to save all data entries in a persistent manner, my question is do I need to implement JPA? I think that the worst case scenario is that my end users host computer goes down sometime during the Database write processing and that Database element may be corrupted. That thought is what led me to learning about JPA to persist the Database transaction. Do I need to implement JPA or is there a better way to achieve my persistence goal? Regards, Jim... -- View this message in context: http://apache-database.10148.n7.nabble.com/JPA-required-tp127242.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: JPA required?
Just a quick tip: Derby's documentation includes examples and tutorials that do not use JPA. Start here and work your way through Activities 3 and 4: http://db.apache.org/derby/docs/10.9/getstart/index.html Hope that helps. On Wed, Feb 13, 2013 at 2:13 PM, Bergquist, Brett wrote: > For your use case, probably not. JPA is not something that is going to > solve a database element corruption and in fact with JPA and its normal > use, you have less control when entity changes are flushed to the database. > > Note that if you don't have your database stored on medium that has write > caching, if the host computer goes down, the database is not going to be > corrupt; it might not have the latest change, but it will be consistent if > you are using transactions. > > -Original Message- > From: JimCrowell37 [mailto:jimcrow...@email.com] > Sent: Tuesday, February 12, 2013 4:52 PM > To: derby-user@db.apache.org > Subject: JPA required? > > Hello, > > I have spent today reading up on JPA and I have a question if I really > need it. > > I have a data entry form class where each data entry field is associated > with an element of a Derby dynamic database table. As each data entry field > looses it's form focus, I shall write the entered data entry value to the > Database table. The Database table primary key is the fields row / column > indices. > > Since my goal is to save all data entries in a persistent manner, my > question is do I need to implement JPA? > > I think that the worst case scenario is that my end users host computer > goes down sometime during the Database write processing and that Database > element may be corrupted. > > That thought is what led me to learning about JPA to persist the Database > transaction. > > Do I need to implement JPA or is there a better way to achieve my > persistence goal? > > Regards, > Jim... > > > > -- > View this message in context: > http://apache-database.10148.n7.nabble.com/JPA-required-tp127242.html > Sent from the Apache Derby Users mailing list archive at Nabble.com. > > >
RE: JPA required?
Bergquist, Brett-2 wrote > For your use case, probably not. JPA is not something that is going to > solve a database element corruption and in fact with JPA and its normal > use, you have less control when entity changes are flushed to the > database. > > Note that if you don't have your database stored on medium that has write > caching, if the host computer goes down, the database is not going to be > corrupt; it might not have the latest change, but it will be consistent if > you are using transactions. Brett... My Derby Database is hosted on my HDD in a /db folder under the Java Application folder... >" ... if you are using transactions." The above phrase made me look at my code to see if I am using transactions. I wrote the derby software some time ago and I have the following lines of code but I do not understand why I did the "conn.setAutoCommit(false)" statement... // Control transactions manually... // NOTE: Auto commit is on by default in JDBC... conn.setAutoCommit(false); Everything is working fine but I wanted to assure myself that the above operation is OK. Many Thanks, Jim... -- View this message in context: http://apache-database.10148.n7.nabble.com/JPA-required-tp127242p127277.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: JPA required?
José, José Ventura-3 wrote > Just a quick tip: Derby's documentation includes examples and tutorials > that do not use JPA. Start here and work your way through Activities 3 and > 4: > > http://db.apache.org/derby/docs/10.9/getstart/index.html > > Hope that helps. Yes it did help. I have my Embedded Derby Database setup and have several tables created and debugged. I used the tutorial to compare with my Derby code. The Tutorial alerted me that I do not currently shut down my Derby Database when my end user terminates my application. Also, I have a "Soft Abort" capability that also needs to terminate the db. I'll use the Tutorial as a reference when I add the Database termination code... I knew about the Network Server capability but do not see how I would use it in my stand alone Java application. A subset of my Derby Database shall be uploaded to a 'MySQL' record on my Server. This subset shall then be used to produce application reports via a Web Browser. The subset upload to server processing is, I think, independent to the Derby Database and yet another learning curve for me. Thanks, Jim... -- View this message in context: http://apache-database.10148.n7.nabble.com/JPA-required-tp127242p127279.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: JPA required?
By default, connections start in Auto-Commit mode, which means every statement is executed as a single transaction. http://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html#disable_auto_commit To group several statements in a transaction, you first set autoCommit to false (just like your example); then, execute all the statements you want; and then execute *conn.commit()* (or *conn.rollback()* if you detect an error). Since you said everything is working, I assume there is a call to conn.commit() somewhere in your code. If the call to commit() is being made "too soon", such as after each statement (kind of what happens with autoCommit on), and the host goes down between statements, you have to worry about consistency yourself. Consider a program that withdraws money from one bank account, commits, then deposits into another account, then commits: if the host goes down between commits, some money just disappeared. On the other hand, if the call to commit() is being made "too late" (only when the user quits the program, for example), then if the host goes down before that, none of the new data will be in the database. It will still be consistent, but data will have been lost. What you need to do is find out what statements (if any) should be grouped in atomic blocks for your application, then commit() each time one of those blocks finish. On Wed, Feb 13, 2013 at 5:28 PM, JimCrowell37 wrote: > Bergquist, Brett-2 wrote > > For your use case, probably not. JPA is not something that is going to > > solve a database element corruption and in fact with JPA and its normal > > use, you have less control when entity changes are flushed to the > > database. > > > > Note that if you don't have your database stored on medium that has write > > caching, if the host computer goes down, the database is not going to be > > corrupt; it might not have the latest change, but it will be consistent > if > > you are using transactions. > > Brett... > My Derby Database is hosted on my HDD in a /db folder under the Java > Application folder... > > >" ... if you are using transactions." > The above phrase made me look at my code to see if I am using transactions. > I wrote the derby software some time ago and I have the following lines of > code but I > do not understand why I did the "conn.setAutoCommit(false)" statement... > > // Control transactions manually... > // NOTE: Auto commit is on by default in JDBC... > conn.setAutoCommit(false); > > Everything is working fine but I wanted to assure myself that the above > operation is OK. > > Many Thanks, > Jim... > > > > > > -- > View this message in context: > http://apache-database.10148.n7.nabble.com/JPA-required-tp127242p127277.html > Sent from the Apache Derby Users mailing list archive at Nabble.com. >
Re: JPA required?
José José Ventura-3 wrote > By default, connections start in Auto-Commit mode, which means every > statement is executed as a single transaction. > http://docs.oracle.com/javase/tutorial/jdbc/basics/transactions.html#disable_auto_commit > > To group several statements in a transaction, you first set autoCommit to > false (just like your example); then, execute all the statements you want; > and then execute *conn.commit()* (or *conn.rollback()* if you detect an > error). Since you said everything is working, I assume there is a call to > conn.commit() somewhere in your code. > > If the call to commit() is being made "too soon", such as after each > statement (kind of what happens with autoCommit on), and the host goes > down > between statements, you have to worry about consistency yourself. Consider > a program that withdraws money from one bank account, commits, then > deposits into another account, then commits: if the host goes down between > commits, some money just disappeared. > > On the other hand, if the call to commit() is being made "too late" (only > when the user quits the program, for example), then if the host goes down > before that, none of the new data will be in the database. It will still > be > consistent, but data will have been lost. > > What you need to do is find out what statements (if any) should be grouped > in atomic blocks for your application, then commit() each time one of > those > blocks finish. What a great explanation, thanks. I just looked at my code and I see that I only do the "conn.setAutoCommit(false)" statement during Database initialization methods[twice]. I do, however do the "conn.commit()" statement in all the methods I have written to perform Database operations. I think that all of these methods only perform one transaction at a time. I'll go back and make sure that is a true statement. I think I just felt that the commit was necessary in my Derby operations code but I do not know why I decided to do the conn.setAutoCommit(false) operation? My derby code is somewhat basic and not to complex but I am thankful for your info in case I need to write something more interesting someday. Regards, Jim... -- View this message in context: http://apache-database.10148.n7.nabble.com/JPA-required-tp127242p127281.html Sent from the Apache Derby Users mailing list archive at Nabble.com.