Glenn, Although we aren't using them with specific SB+ calls, we use uodotnet connections, managed in pools through MS Enterprise Services (COM+). These call programs in SB+ accounts which have an SB+ common but aren't calling any SB+ processes, so don't need to go through SB+ security or common setup.
The ES pooling objects are setup so that when a .net process requests a db connection, it will either grab an existing unused connection from a pool or if it can't find a free one, initiate a new connection (up to a set number of connections). Once a process has done with a connection object it will release it back to the pool. These connections stay inactive in the pool for a period of time after which the object will close the connection and release it's resources. ES gives you the option of .net transaction management as well, though we haven't tried this with uodotnet. So, when one of the connections is instantiated, we use a setup method to do login and call a UniBasic subroutine to setup common. The connection and common will stay set until the object is retired from the pool. This method has the same startup latency for the 1st use but significantly decreases the setup time for all subsequent uses of the connection object, which is what I think you're after. Obviously, this means care has to be taken when using common. You have to ensure that for any process you can gaurantee its state. In the case of an SB+ session, for each account and sysid, you would probably have a different pool of connections; a .net process can then go and grab a session for account "SBDEMO" with sysid "CH". You would have a startup initialisation, which opens files and sets up your "section 3" for CH, and a secondary initialisation for subsequent use which lightly resets "section 1 & 2" of the SB common. Another place you might look is the mv.Net product, they seem to have pooling covered, so the theory would be the same. I hope that gives you some ideas at least. Stuart. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of "Glenn Batson" <[EMAIL PROTECTED]> Sent: Friday, 27 January 2006 10:12 To: <[email protected]> Subject: [U2] UO.NET and SB+ I sent this to SB+ solutions but I also thought someone here might have some opinions. Sorry if this has been discussed before. I'm having problems getting to indexinfocus.com to do a search. Is anyone using UO.NET in an environment that includes SB+. We are and to get into SB+ we have a wrapper subroutine that passes data through COMMON to an SB+ aware subroutine called by SB.REMOTE.PROCESS. I would like to know what other approaches may be used. One concern for us now is the overhead of the login logic that occurs every time. We are not trying to get around the license but are concerned with the processing overhead. In other words for every API call that calls a routine that uses SB+ we call SB.REMOTE.PROCESS which has to go through a login. I would like the login to stay persistent through the life of the connection pool connection. Does anyone have any suggestions or other secret ways of handling what we are trying to do? I know the initial response is why not use RedBack. We had a bad experience with RedBack and therefore went away from it. I definitely don't want to say RedBack is bad, because it may have been our own fault in how we implemented it. We just have a sour taste in our mouths and will not go back. Actually we ended up using SB.REMOTE.PROCESS in the RedBack world also because stateless RBOs did not support SB+ execution. Any input would be appreciated. Glenn Batson www.jenkon.com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ********************************************************************** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (+61 3 9269 7555) immediately, who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer related viruses. ********************************************************************** ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
