Sorry I used flush incorrectly I was using it because it was used
previously in the message and I use it in other areas to ensure db
changes made externally are updated in the objects correctly.
Thanks for the help.
> -------- Original Message --------
> Subject: Re: Glassfish Shutdown with JPA
> From: Marina Vatkina <Marina.Vatkina_at_Sun.COM>
> Date: Thu, October 16, 2008 8:23 pm
> To: persistence_at_glassfish.dev.java.net
>
>
> flush() doesn't cause the commit. You can to call a SLSB method with tx
> set to REQUIRES_NEW for each persist if you want to make sure all of
> them ar in the database at any point of time.
>
> Regards,
> -marina
>
> Dru Devore wrote:
> >> -------- 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.
> >>>>>>> >
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >
> >