弹性和数据并发
我很快就要开始一个中等规模的项目。尽管这在我要做的大量事情中并不是一个非常高的优先级，但我一直在尝试如何有效地处理数据并发性。 我将在我的 Flex 应用程序中使用无状态 EJB 后端。
理想情况下，我正在寻找一种简单的方法来处理数据并发性。例如，如果数据保存在一个界面上，则会在另一个界面上刷新。或者在保存新版本的数据之前警告数据已更改。
有没有人有任何想法，因为我现在很茫然。正如我提到的，这不是一个高优先级，但如果我有一些机制来改进流程，我会感觉好多了。
I am soon to embark on a medium scale project. Although this isn't a very high priority in my large list of things to do but I have been trying of how I could affectively handle data concurrency.
I will be using a stateless EJB backend to my flex application.
Ideally I am looking for a simple method to deal with data concurrency. e.g. if data is saved on one interface it is refreshed in another. Or it warns that the data has been changed before saving a new version of the data.
Has anyone any ideas as I am at a loss at the moment. As I mentioned its not a high priority but I would feel a lot better if I had some mechanism to improve the process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您计划使用 AMF 通道进行通信，您可以使用长轮询功能来有效地为您的应用程序提供“推送消息”类型的支持。 BlazeDS 和/或 GraniteDS 数据服务都支持此功能，原因正是您提到的。
If you are planning on using AMF channels for communication you can use the long polling feature to effectively give your application "push message" type support. Both the BlazeDS and/or GraniteDS data services support this capability for exactly the reasons you mentioned.
版本控制系统存储每个修订的 user_id 和日期时间。您可以使用相同的方法。客户端应用程序获取所请求数据的当前日期时间并保存。应用程序发送更改的数据并保存日期时间。服务器检查上次修订的日期时间和收到的日期时间。并相应回复应用程序。
第二种方法是使用从服务器到客户端的广播消息。但我认为它不适用于您的情况。该方法通常在局域网（连接稳定的环境）中实施。
Version control systems store user_id and datetime for every revision. You can use same method. Client app get current datetime for requested data and save it. App send on changed data with saved datetime. Server checks datetime of last revision and received datetime. And reply to app accordingly.
Second method is using broadcast messages from server to clients. But I don't think it's applicable in your case. This method put into practice in LAN (environment with stable connect) usually.