Shutdown would not work. It was hung on the shutdown as well. Actually the time to recover is going to be 50 hours which we don’t have. We have had to go back to a backup of the database two days ago since the backup of the database done last night also contained these log files.
What about transactions that are not prepared? I think this is a hole here. If an application were to xa-start, execute some SQL, xa-end, but never xa-prepare and the application fails (crash), the transaction remains in Derby. If the transaction required locks, then those also remained locked. So what is ever going to clean that up. The XAResource.recover never sees those transactions. On Mar 25, 2016, at 1:35 PM, Katherine Marsden <[email protected]<mailto:[email protected]>> wrote: On 3/25/2016 9:39 AM, Bergquist, Brett wrote: Hey Kathey, that for taking the time to respond. Unfortunately we had to bounce the network server and not it is going through the derby recovery logs. 18000 of them at one every 10 seconds. So 5 hours of down time ☹ Thanks Brett for looking at this issue and filing the issue. Maybe next time try connecting to network server and shutting down the database with shutdown=true first to minimize the downtime going through the logs. I should have mentioned that in my first response. A couple other things that came to mind. I think recover shouldn't recover transactions that are not prepared. I think maybe in your simple test case the session was still hanging around and that is why you saw the transaction, but I could be wrong. Best Kathey ________________________________ Canoga Perkins 20600 Prairie Street Chatsworth, CA 91311 (818) 718-6300 This e-mail and any attached document(s) is confidential and is intended only for the review of the party to whom it is addressed. If you have received this transmission in error, please notify the sender immediately and discard the original message and any attachment(s).
