Glenn Stateless is more performant than stateful that's true - but the design and setup of the RBOs is just as much - if not more - important. On a like-for-like flat performance basis stateless wins every time.
The downside of UO is that you have an inbuilt setup time (establishing connection / session / login credentials / etc). You can avoid this by having either using RedBack (stateful or stateless) or writing your own connection pooling interface. Horses for courses - if you were to use SBObjects you don't have to take the initial connection hit or write a connection pool. If you use RedBack (SBObjects or not) it comes with inbuilt connection pooling, throttling of licenses etc. You also get to use the inbuilt SB+ functionality to invoke SB+ processes and dependencies (based on the properties of a user or user group) which you would not otherwise have. For flat performance use stateless RBOs - but you can get the equivalent by writing your own add-ons. As usual it comes down to product costs vs. in-house development costs. My personal preference is RedBack in stateless mode..... (but you could probably tell that). UO is fine but doesn't scale as easily. Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Batson Sent: 29 January 2006 00:16 To: [email protected] Subject: 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: [email protected] 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: [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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
