Axton,
<IMHO>
"
The questions are these:
- Do you feel this would be a worthwhile time investment on BMC's part?
"
It should be multi-threaded for read... but single threaded for write.
I think it would greatly reduce the amount of changes needed in the
code line.
I would think that that simple change could even be made by only
altering the Admin tool client. (any "SET/CREATE/DELETE" API call is
routed to RPC 390600, any "GET/GETLIST/etc" are routed to a second RPC
which could be configured in the client or default to no RPC
specified.) The only issue I see with that would be that a race
condition could present itself when Developer #1 changes and saves the
ARS object after Developer #2 has retrieved and changed, but not yet
saved the same object. I would be 100% ok with the "Another user has
modified this Object" type message that forces Developer #2 to either
"Save As..." the object or close it. If your using a Source Control
(SC) system and locking the object then this condition would be
completely avoidable too.
Or Remedy could simply force the use of their internal object SC data
without calls to an external SC system and do "auto locking" of the
object when it is first opened in the Admin tool by Developer #1 too.
"
- Would this ease contentions in your environment?
"
Yes. I live in a multi-developer environment. But it would not
solve all "development issues".
And I really doubt that BMC really cares about these issues in
ARS. I get the distinct feeling that the push is to make ARS into a
Engine that they use to sell other products, more than a development
platform that others can use to create products to sell. Sure they
want their customers to be able to change things, but do they really
want them developing applications that they could have sold to them? I
really think this is the double edged sword that the BMC management
has decided to swing in the other direction. The OOB apps are getting
more complex (exponentially?) and the quality of the support and
training is going way down. Those factors combined will force
continuing customers to be more dependent on BMC and less independent.
Factor in the how the Partners and RSP's have been handled in recent
years and I am left with a strong doubt that BMC wants to sell ARS as
a development platform without an OOB application to any customer.
(Which is a sad state of affairs if you ask me.)
However... I think your third question is the most interesting of the set...
"
Do you think the BMC engineers are up to it?
"
Maybe they do not want to change the Admin tool at all. Maybe they
would rather stop making an Admin Tool and push everything into the
Mid-Tier?
Maybe they are trying to get to the point that they start using
real RDBMS row locking to do all of this anyways?
Maybe (these days) there is less of a plan than one would hope and
they are just "figuring it out as they go". (And shipping the labor to
the cheapest places they can to maximize profit. Which would also
minimize the long standing, ingrained institutional knowledge of what
ARS was always intended to be... a development platform for the
customer to integrate their systems with their business processes. )
</IMHO>
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
Never ascribe to malice, that which can be explained by incompetence.
On 8/10/06, Axton <[EMAIL PROTECTED]> 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
