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.
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>
>