RE: [U2] UO.NET and SB+
Glenn If you were considering a WWW route then RedBack supports SBObjects directly and gives you a connection pool while at the same time being SB+ aware. Regards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Batson Sent: 26 January 2006 23:12 To: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UO.NET and SB+
My understanding is the sbobject is the state based implementation and was too slow. My understanding was the stateless was more performant but not sb aware. Again past experience keeps is from going back. -- Sent from my BlackBerry Wireless Device -Original Message- From: [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Sat Jan 28 05:54:41 2006 Subject: RE: [U2] UO.NET and SB+ Glenn If you were considering a WWW route then RedBack supports SBObjects directly and gives you a connection pool while at the same time being SB+ aware. Regards JayJay -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Batson Sent: 26 January 2006 23:12 To: u2-users@listserver.u2ug.org 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 u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
