L.J. I am not sure I can "speak authoritatively" on this as this is mostly "black magic" that the ARS server does for licensing/performance reasons. (And on the whole BMC, nor Remedy of old, has been too inclined to share such detailed internal logic with customers. We really do not need to understand it. We just have to be users of it. :)
However, as far as I know, the only thing that rebuilds the internal cache table is the arcache utility. I know of no condition, even a stop/start of the ARS server, that the ARS server will rebuild the entire table. It will updated it (or should as this incident points out) when relevant corresponding data is changed via the User form(s) on a record per record basis. My only thought for how things could be out of sync.... 1) A bug in the ARS server. ( Bugs have been known to happen from time to time.) And this is a very remote #2 option.... I have never proven this condition to be identified, especially repeatably, in the real world. It is just a theoretical discussion.... 2) Your RDBMS bit you. The way the ARS server does commits to the DB may or may not be all in one RDBMS transaction. There are times that part of the work is done on the DB before other parts of the ARS transaction is completed. If other parts of the ARS transaction "fail" then the ARS server should do a logical "role back" of the RDBMS changes it made earlier in the transaction. I have seen this work as advertised. So I doubt the issue lies with this feature, but it could be another source for a bug too. 2A) It however is potentially possible that the RDBMS could role back some change in the user_cache table without the ARS server seeing that as a "failure" in the ARS transaction too. (Or your DBA could muck with the table, or you could muck with the table, etc...) I doubt that helps much, but since you asked, that is what I know about it. :) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 3/30/07, L. J. Head <[EMAIL PROTECTED]> wrote:
I didn't think that restarting the Remedy Server rebuilt the cache...hmmm...maybe Carey or Axton could speak authoritatively on this subject -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of ARSList Sent: Friday, March 30, 2007 12:48 PM To: [email protected] Subject: Re: User Cache Issue You said your Server kept the user cache even after your server was restarted? I think I just read a KM about this, of course, I didn't keep it. But I thought the Remedy server sometimes keeps the user email in certain situations, but restarting either the Server and/or the email engine is supposed to clear this out. You should be able to find something about it with "email user" or "group email". I seem to recall having a problem with group email at the time. Good luck. Havin' Fun in Sacramento. Nick -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Heider, Stephen Sent: Friday, March 30, 2007 10:02 AM To: [email protected] Subject: User Cache Issue An unusual situation happened today that is now resolved, but I want to understand how it could occur. An employee's email address changed. The employee has a record in User with a Read-Restricted license. When an email (any email) was sent from Remedy the AR System Email Messages form would list their old email address. The old email address does not exist anywhere in the system. I restarted the Email Engine NT service and then ran arsignal with the -u switch to reload the user data. When that didn't fix it I restarted the Remedy NT service (surely, this had to work). When that didn't work I opened her record in User, removed the email address, saved, re-entered the email address, and saved. That fixed it. I'm thinking the user_cache table kept the old email address but I presume that it should have been reinitialized when arsginal was run or when the Remedy NT service was restarted. How could this situation occur? Thanks. ARS 6.3 p16 Windows Server 2003 SQL Server 2000 Stephen
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
