WebObjects/EOF/使用 EOF/并发
我们试图修复一些我们一直在遇到的编辑上下文问题，并且我们正在考虑创建类似于以下架构的架构
首先注意... 我们有 WOAllowsConcurrentRequestHandling = true
- 创建一个 ThreadLocal 来延迟实例化一个 EOEditingContext，它有自己的新 EOObjectStoreCoordinator
- 当一个直接动作请求进来时，在 performActionNamed 中向 ThreadLocal 请求它的编辑上下文。
- 在 try 块中锁定 ThreadLocal 的编辑上下文。
- 处理请求并调用 generateResponse()。
- 在 finally 块中解锁 ThreadLocal 的编辑上下文。
- 返回响应。
所以我们最终会为每个工作线程获得一个到数据库的单独连接。因此，我们可能会有很多到数据库的连接。当工作线程完成时，我们将关闭到数据库的连接。我们最终可能会使用 JavaPoolingJDBCAdaptor 来限制到数据库的连接。但这将为我们应用程序提供良好的多线程并发访问。
有人预见到这种方法有任何不良影响吗？我在 WO 开发档案中从未见过这种方法被提出。我的一位开发者建议了这种方法，我认为听起来不错，所以我想先看看其他人有什么想法，然后再实施它。如果它运行良好，我们将很乐意分享我们的发现和代码。
我曾在以这种方式构建的应用程序上工作过，并且不满意。只是让你知道我的来历 :-)
几点想法
- 你将拥有多个快照 - 每个 EOObjectStoreCoordinators 都对应一个。它们不会同步。因此，您将失去乐观锁定，并且必须要么实现某种跨堆栈通知，要么通过频繁获取确保新数据（牺牲缓存）。
- 您将使您的应用程序架构变得复杂，使其更难维护，更难理解，也更难交接给其他 WebObjects 开发人员。
- 您是否真的需要对所有查询都进行多个并发连接到您的数据库？我可以理解对配置文件已确定为瓶颈的查询这样做。但是，如果可能的话，我可能会查看其他优化（例如：将尽可能多的负载转移到 SQL 服务器）。
- 多个实例（尽管硬件成本更高）将更加干净，也更易于维护（即使*使用*实现更改通知架构）。
与往常一样，这些意见仅代表我个人观点，并欢迎讨论 :-)
在锁定方面，我认为这将没问题。最有可能遇到的问题是内存使用。额外的 EOF 堆栈将比单个堆栈实现消耗更多内存。我假设这对于你的目的来说是可以的，即请求不会获取很多数据。如果它们确实获取了大量数据，或者你最终拥有许多工作线程，你可能会发现你的应用程序很快就会耗尽内存。您可能需要考虑对应用程序级别存储的一组堆栈进行某种循环使用。这至少会在一定程度上限制内存使用。您也可能会因此在数据库中遇到更多乐观锁定失败。如果您正在运行多个实例（我记得这是这种情况），那么您必须无论如何处理这些问题，因此这将不再是一个问题。