OK. This makes sense: if in transaction, it is not entered/left/autocommited by apply, assuming that there is an upper level transaction.
On error in this case, rollback will not happen, and the calling code is responsible. Another use case, which I hesitate to consider automatable, is importing hierarchies allowing errors within a single transaction, such as accounts and their operations. One way to do this is to use one transaction, prepare several statements, and cycle through items of the same type for the same ancestors. This should gain speed, but smells like overdesign. The other two more reasonable approaches are used in making Phrase DB in JHP demo. ----- Original Message ---- From: bill lam <[EMAIL PROTECTED]> To: General forum <[email protected]> Sent: Wednesday, September 27, 2006 10:04:40 PM Subject: Re: [Jgeneral] SQLite new addon Oleg Kobchenko wrote: > As the error processing for SQLite is naturally incorporated > with J signal, SQLite will throw an error "cannot have nested > transactions" already, which will be thrown in J. > So there is no need to maintain this just > to throw a different custom signal. > > Does that make sense? I'm not sure. I guess your intent of start a transaction within apply is to assure atomicity and faster speed. Should them be already assured by an existing transaction, then 1. it is redundant 2. it raise superfluous "cannot have nested transactions" error 3. it becomes impossible to use apply within user started transaction. -- regards, bill ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
