MS CRM 中的自动编号
我知道这是一个古老的讨论，但仍然是一个开放的讨论。
场景很简单，您有一个实体（例如帐户），其中包含名为“AccountId”的属性 应该是自动递增的。
一个主要候选者是在活动前注册的插件。
有不同的选择可以满足这一需求。
- 获取最大数量，增加它并分配给 AccountId 属性。
- 依赖某些外部源（例如某些 Web 服务或数据库）来执行此作业。 （这不是一个好方法）
这些方法是在这里讨论。
就我个人而言，我赞成方法 1，但我有一些担忧：
1-并发请求的重复
锁定和互斥可以减少这种情况，但是在“农场环境”的情况下可以采取什么措施来避免此问题？
I know it's an old discussion but still an open one.
Scenario is simple you have an entity say account which contains a attribute named "AccountId"
which should be auto incremented.
A prime candidate for this is Plugin registered on Pre event.
There are differnt options available to cater this.
- Get max number, increment it and assign to AccountId attribute.
- Rely on Some external source e.g. some web service or db to perform this job. (Which is not a good approach)
These approaches are disccused here.
Personally I am in favour of Approach 1 but I have concerns:
1- Duplication on concurent requests
Locking and mutex can reduce that but what can be done to avoid this problem in case of "Farm environment"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
“场环境”（实际上意味着安装了前端角色的多台服务器）中的问题是您几乎无法避免计数器值的重复。
使用锁或互斥锁，您只能在单机环境中实现一致性。
如果您需要可靠的编号，您应该使用生成编号的服务或专用数据库（这意味着不是 CRM 数据库，因为这不受支持）作为后端，您可以在其中通过锁协调请求。
The problem in a 'Farm environment', which actually means multiple servers with the front-end role installed, is that your are hardly able to avoid the duplication of your counter values.
With locks or mutexes, your are only able to achieve consistency in a single machine environment.
If you need reliable numbering, you should use either a service which generates the numbers or a dedicated database (that means, not the CRM database as this would be not supported) as back-end where you could coordinate the requests with locks.