> -------- Original Message --------
> Subject: Re: Glassfish Shutdown with JPA
> From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
> Date: Thu, October 16, 2008 4:49 pm
> To: persistence_at_glassfish.dev.java.net
>
>
> Dru Devore wrote:
> >>-------- Original Message --------
> >>Subject: Re: Glassfish Shutdown with JPA
> >>From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
> >>Date: Wed, October 15, 2008 5:27 pm
> >>To: persistence_at_glassfish.dev.java.net
> >>
> >>
> >>Dru,
> >>
> >>I need to check with our container people, but transaction shouldn't be
> >>committed in the middle of a business method. It's either rolled back or logged
> >>in the transaction logs (if it's an XA resource) for the future recovery.
> >
> >
> > I am not using XA. The transaction is only there so that the EJB timer
> > will not expunge itself if an error is encountered. If a DB exception
> > happens I can't keep it from getting to the server. Once it happens
> > twice the EJB timer is killed with no notification to the application
> > and the only way I have found to keep this from happening is to wrap the
> > code the timer is calling in a transaction. Any other ideas I am all
> > ears.
>
> You can change the default to have as many redelivery attempts as you like (see
> <ejb-timer-service max-redeliveries=... in domain.xml)
>
I saw this but I am controlling this because I need to be able to report
the error and stop based on a configuration setting. So simply
increasing the redelivery attempts does not work because I do not get
any notification of the error.
> >
> >
> >
> >>JPA doesn't have XA recovery capabilities by itself, only XA resources do, so
> >>unless the changes are flushed into a database, *and* you are using an XA
> >>resource, the recovery won't happen.
> >>
> >>It's probably too expensive for your method to flush after every persist() call,
> >>so you can either try to do flush() every N persist() or split those 1150+
> >>inserts into smaller transactions.
> >
> >
> > The case of the 1150 or so was simply because the server was running the
> > process as normal. Normally there are not nearly that many and the
> > transaction could very easily be cut down into a much smaller section of
> > code basically what is inside the while, actually I don't even need a
> > transaction for this.
> >
> > Unless there is a better idea I think I am going to go with a flush()
> > after each persist.
>
> If you are not using an XA resource for your JPA data, there will be no recovery :(.
I am not wanting recovery. I want the commits to not be rolled back. So
flush() is sounding good.
>
> Regards,
> -marina
>
> >
> >
> >
> >>Regards,
> >>-marina
> >>
> >>Dru Devore wrote:
> >>
> >>>>-------- Original Message --------
> >>>>Subject: Re: Glassfish Shutdown with JPA
> >>>>From: Mitesh Meswani <Mitesh.Meswani_at_Sun.COM>
> >>>>Date: Wed, October 15, 2008 2:49 pm
> >>>>To: persistence_at_glassfish.dev.java.net
> >>>>
> >>>>
> >>>>Dru Devore wrote:
> >>>>
> >>>>
> >>>>>I have a timer that goes through a list of objects, performs an action
> >>>>>on it, logs the object, sets a boolean, and persists it back to the
> >>>>>database. The boolean indicates that the object is finished and should
> >>>>>not be acted on again. So I have the following sudo loop:
> >>>>>
> >>>
> >>>
> >>>New Transaction --- (This is all contained in a single EJB method that
> >>>requires a new transaction)
> >>>
> >>>
> >>>>>list objects = get object from the database
> >>>>>while (more objects) {
> >>>>> act on object
> >>>>> log the object
> >>>>> set boolean
> >>>>> persist object
> >>>>>}
> >>>
> >>>End Transation ---
> >>>
> >>>
> >>>
> >>>>At what point does the transaction commit happen?
> >>>>
> >>>>
> >>>>>I had a list size of 1152 the other day and during the loop I shut
> >>>>>down the server. After I started the server back up I noticed that it
> >>>>>was logging the same objects again. I checked the logs and saw that
> >>>>>all the actions and persistence happened
> >>>>
> >>>>Did you actually see update statements going to database in the log?
> >>>
> >>>
> >>>I have not seen any update statements from the the JPA classes. I know
> >>>the update works though because the only time I dont get the boolean
> >>>updated is when I shut down the server in the middle of the processing.
> >>>
> >>>I am guessing that I am going to have to implement a finer grained
> >>>transaction to get the action I want.
> >>>
> >>>Let me ask another question while I have your attention.
> >>>
> >>>Another situation:
> >>>I perform a query and get a list of objects. I then change the data
> >>>directly in the database but when the same object is queried again the
> >>>changes made directly through sql are not reflected in the object. I
> >>>tried to flush the object but I have not seen it work solve the problem.
> >>>
> >>>
> >>>
> >>>>Thanks,
> >>>>Mitesh
> >>>>
> >>>>
> >>>>>as it should have but the DB simply was not reflecting the boolean
> >>>>>indicator properly though I know it was set and persisted.
> >>>>>
> >>>>>So it appears that the objects were simply not transfered from the
> >>>>>cache to the DB. I am using EJB 3 with toplink.
> >>>>>
> >>>>>
> >>>>> -------- Original Message --------
> >>>>> Subject: Re: Glassfish Shutdown with JPA
> >>>>> From: Mitesh Meswani <Mitesh.Meswani_at_Sun.COM>
> >>>>> Date: Wed, October 15, 2008 2:19 pm
> >>>>> To: persistence_at_glassfish.dev.java.net
> >>>>>
> >>>>> Can you please give some more details on what do you mean by "does
> >>>>> not
> >>>>> appear to be saving the JPA persisted objects before shutdown.".
> >>>>> Objects
> >>>>> saved using em.persist() will be saved to database at each
> >>>>> transaction
> >>>>> completion. There is nothing special you will need to do.
> >>>>>
> >>>>> -Mitesh
> >>>>>
> >>>>> Dru Devore wrote:
> >>>>> > I have an application which does not appear to be saving the JPA
> >>>>> > persisted objects before shutdown.
> >>>>> >
> >>>>> > Yes, the objects are being persisted before the shutdown but it
> >>>>> > appears that they are not making it out of the cache. Is there
> >>>>> > something I have to do during shutdown of the application server to
> >>>>> > ensure the objects are actually stored.
> >>>>> >
> >>>>> >
> >>>>>
> >