"Do you feel this would be a worthwhile time investment on BMC's part?"
Yes I do... There has been more than once in the past when I have been a part of a larger development group and have encountered that ever to wonderful slow down because on a single thread for administration. That pain has been there for so long that I think that we have learned to live with it. "Would this ease contentions in your environment?" If I were working for a larger shop again, perhaps. I cannot speak to it properly presently, but if I were to take a stab at it, I would assume that the model which I believe that the AR System developers took was that there would be a restricted number of developers/administrators working with the application at any one point. Now this worked fine for a number of years, and probably still does for most. The only areas where it becomes a pain is when there are multiple developers working on multiple applications on the same server. Maybe in this way, the AR System is a victum of it's own success, as there is that - and stop me if you have heard this before - the 'get it into Remedy' mantality. Don't get me wrong, I can appreciate that approach, but it can be a challenge sometimes. "Do you think the BMC engineers are up to it?" <uncertain headshake> Around here we call a question like that - bait. :-) My guess would be that, if they wrote it, they can do it. > > > > > On Thu, August 10, 2006 1:05 pm, Axton wrote: > >> I wanted to get a sense of whether people thought having a >> multi-threaded admin queue would be a good thing for a Remedy server. >> >> In other development environments/efforts, people are able to >> checkout/commit portions of code, thus only blocking operations related >> specifically to those objects. In the arsystem, all admin operations >> are blocked by any admin operation. >> >> This would address many problems this presents with the arsystem >> environment: >> - Multiple developers >> - Processes that use the admin queue (approval server, cmdb, etc.) not >> occupying the queue from other, unrelated operations >> >> Though, at the same time, it would introduce inherent complexities >> within the arsystem server: - Granular object locking (locked at the api >> operation level, not an object checkout model) - Thread collisions due >> to recursive operations >> >> The questions are these: >> - Do you feel this would be a worthwhile time investment on BMC's part? >> - Would this ease contentions in your environment? >> - Do you think the BMC engineers are up to it? >> >> >> >> I am anxious for your thoughts. >> >> >> >> Axton Grams >> >> >> >> _______________________________________________________________________ >> __ >> ______ >> UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org >> > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
