We are real familiar with this situation. SB+ uses an extensive Common block and we have developed techniques to maintain that common block no matter what responder the application uses. Our program XLr8 maintains the information so that you application backend code will be able to run with none or little modification. The one exception is, of course, locking. Redback does not support persistent locking and either does XLr8.
Doug www.u2logic.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Percival Sent: Sunday, February 27, 2005 10:25 PM To: [email protected] Subject: RE: [U2] RedBack and Named Common At 09:24 PM 27/02/2005 -0600, you wrote: >I thought that RedBack stayed 'logged on' to the designated account, >however, since you have no idea if you will return to the same 'serving >spider', that's where the named common gets sticky... I am not 100% certain on this point. However if you cant guarantee returning to the same connection then the answer is _effectivly_ the same, that is you gain nothing by putting information into named common. >If your named common did nothing else other than have the list of 'opened >files' that were common amongst your application, I think that would behave >- where you get into trouble is in the case of lock and persistence since >you may not/will not return to the same connection, and in the mean time, >even if you did, the same session may have/will have served other users. >So, variables in memory that pertain to a given session would not serve much >use in Named Common. And this is the overriding problem. Whilst we do use named common to reduce the amount of file open's performed we also stack a lot of _user specific_ information up there including, user name, user ID and terminal number(location) for auditing purposes. NB this is not the Universe id's it is actually related to the application so I cant get around it using system variables and the like ;-( So bottom line is I guess that I have to rework our code so that we reinitialize common on every call rather that only at the beginning. Thanks .....Darren..... ============================================ The generation of random numbers is too important to be left to chance. ============================================ ------- 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/
