You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by JimCrowell37 <Ji...@EMail.com> on 2013/02/12 22:52:13 UTC
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?
Posted by JimCrowell37 <Ji...@EMail.com>.
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.
Re: JPA required?
Posted by José Ventura <st...@gmail.com>.
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 <Ji...@email.com> 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?
Posted by JimCrowell37 <Ji...@EMail.com>.
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?
Posted by JimCrowell37 <Ji...@EMail.com>.
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?
Posted by José Ventura <st...@gmail.com>.
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 <BB...@canoga.com>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:JimCrowell@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?
Posted by "Bergquist, Brett" <BB...@canoga.com>.
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:JimCrowell@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.