> any derby rule or good practice how many commits are to be > done in respect of how much memory is assigned to the JVM derby resides in?
In general, a commit should be performed at the completion of a natural unit of work in your application, to tell the database that you are finished making your changes, and desire them to be permanent and made available to other concurrent users. Sometimes, an application may wish to commit at intermediate points, for example if the application can thus be made re-startable upon a system crash or other failure. If I had a program that needed to run for (say) 3 hours each night, but I could make it commit its work periodically, and then be able to restart it from the point of last commit if it should fail, that might be nice, but that's a lot of extra complexity in the application design and I usually don't bother. The only other reason to issue a commit prior to the completion of your task is if the database can't handle a transaction that large. I'm not sure what internal Derby limits you might hit, but if your task is to load a bunch of data into a Derby table, I'd try to do it as a single transaction, and I'd only add additional commits if I got a "transaction too large" error out of Derby when I ran the program during testing. thanks, bryan
