I developed a connection pooling mechanism. This helps with the scalability concerns.
I'm talking java now. I simply found a textbook version using Oracle JDBC connections. It was fairly straight forward to customize it to handle Unisessions instead. I do a couple of extra things when checking a connection back into a pool, such as clearing select lists etc. I also use Named Common on the Universe side to hold file variables. When checking out a connection, I do an ICONV to make sure the connection is still alive. It works very well! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 1:52 PM To: [EMAIL PROTECTED] Subject: RE: [U2] UniObject Problem This is exactly the methodology I use and we've yet to have a problem...Call to COM object, object opens connection, gets data, closes connection. I wouldn't recommend this methodology in an environment where you were dealing with a large number of simultaneous users or transactions, but we've load tested it up to 50 simultaneous users on a Windows 2000 server running IIS (Dual P-4 2GHz, 1.5 GB Memory) along with 100 other users pulling static html without significantly degrading resources and no problems on the UniObjects side of things. ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
