在实践中,我们发现默认的NHibernate(v2.0和2.1)FlushMode = Auto非常昂贵.回顾NHibernate源表明,用于确定需要刷新的内容的算法依赖于在会话中循环遍历所有实体的强力,并且这发生在事务中的每个查询运行中.
在某些生产场景中,对多个项目进行了更新,我们看到使用FlushMode = Auto与FlushMode = Commit相比,该过程要长100倍.
执行涉及多个更新,多个查询等的"复杂"会话逻辑时使用FlushMode的任何想法/建议/最佳实践
有关在nHibernate中优化AutoFlush算法的任何想法吗？
任何人都可以向我提供一个球场时间(以毫秒为单位),表示从C#建立到SQL的新数据库连接所需的时间.即连接池必须创建新连接时的开销是多少.
最新发布的(12月29日)微软安全更新解决了"哈希DoS"攻击漏洞,限制了1000个表单参数.不幸的是,这个限制打破了"非常大"的形式(例如带有动作链接的项目列表,例如200个具有5个复选框的项目= 1000个表单字段).我同意这样的大页面不是很常见,也不是理想的可用但它们确实存在(有时是有充分理由的)并且被新的补丁变得无法使用.
关于vulnrability/microsoft补丁的好消息可以在这里找到:
和
http://www.troyhunt.com/2011/12/has-hash-dos-patch-been-installed-on.html
有没有人有关于如何有效地转换具有> 1000表单字段的旧版ASP.NET表单页面以在修补系统上运行的想法？(除了人为地限制"页面大小"包含<1000个字段)？