Re: mysql pool problem (again)
Hi Dennis, Dennis Bekkering wrote: Hello Tom, Hmm, I'm not too sure why you need this behavior, but I think you should definitely ask the DBCP guys over at the commons-user mailing list. I checked OJB.properties and I am using ConnectionFactoryPooledImpl.class . I kill the connections with the mysql administrator tool, simulating timed out connections. I discovered that the validation query is not called on non transactional requests. Is there a special reason for that? Is it maybe wise to check always when a new broker is called by PersistenceBrokerFactory.defaultPersistenceBroker()? I'm confused. How does this happen. OJB always use ConnectionFactory#lookupConnection to lookup connections and doesn't differ between transactional and non-transactional connections, thus the validation query is always performed. The only difference is the lifetime of the connection associated with the used PB instance. With tx the connection will be closed (returned to pool) on PersistenceBroker.commitTransaction() or PersistenceBroker.abortTransaction(). Without running tx the connection only be closed (returned to pool) on PB.close() call. http://db.apache.org/ojb/docu/guides/connection.html#When+does+OJB+open%2Fclose+a+connection So if you don't close the PB instance after use, the associated connection can be time out. Could this be the reason of your issue? regards, Armin Actually the code where the problem occured needed a transaction so i am happy that i discovered it this way ;-) Cheers, Dennis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mysql pool problem (again)
Hello Armin, I'm confused. How does this happen. OJB always use ConnectionFactory#lookupConnection to lookup connections and doesn't differ between transactional and non-transactional connections, thus the validation query is always performed. The only difference is the lifetime of the connection associated with the used PB instance. With tx the connection will be closed (returned to pool) on PersistenceBroker.commitTransaction() or PersistenceBroker.abortTransaction(). Without running tx the connection only be closed (returned to pool) on PB.close() call. http://db.apache.org/ojb/docu/guides/connection.html#When+does+OJB+open%2Fclose+a+connection You are right i didn't close the broker. I got lazy by the broker per view pattern. But this code was in a scheduler thread and not in an http request so i have to close it after every performed scheduled task. Thank you so much for clearing that out. Cheers, Dennis
Unique keys and OJB having trouble
I'm trying to update a row in a table which has a primary key, 4 unique keys (unique constraint) and a few more data fields. I have naturally one primary key specified for the table in my repository_user.xml file. When I store the row, I get a Unique restraint violation for the unique constraint on the 4 uks. The primary key value is generated using a sequence. Is there any way to configure the table so that it will update the row? Are there any settings you need to do this operation? Jim Wright [Contractor - SRA International] Web Developer Web Development Team Custom Applications Branch (CAB) Division of Enterprise and Custom Applications, CIT/NIH/DHHS 6707 Democracy Blvd, Suite 304 Bethesda, MD 20892 Office: 301. Email: [EMAIL PROTECTED] URL: http://webdev.cit.nih.gov/ http://www.cit.nih.gov/deca
