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)
>
>
>
>>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 :(.
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.
>>>>> >
>>>>> >
>>>>>
>