If a single client miss the event, the consistency is lost and the solution is useless since it cannot be trusted. All the times that I asked core developers about currently events implementation, the answer was that its implementation is weak. I cannot describe what weak means (I have no knowledge of the source), but I guess the problems that I already faced are related with this weak implementation.
With the new proposed feature, there is no client involved, so no events missed at all, and since everything would be run inside the server, it is much more reliable. But there are other points that would need to be addressed, like the isolation, etc.
PS: I don't use NuoDB ;)
[]s
Carlos
http://www.firebirdnews.org
FireBase - http://www.FireBase.com.br
| No, I don't see. What you want to do, and you agreed, could be done with the existence ng event mechanism if yiu could figure out why sometimes it appeared that events weren't being delivered. Instead, your proposing a whole new class of trigger that would require yet another interface, a mechanism to activate and deactivate them, and a secod asynchronous mechanism to modify session variable. It doesn't sound to me like a generally useful mechanism. There are lots of ways to implement asynchronous notification that should be explored before undertaking an overhaul of the existing mechanisms. The one in NuoDB is particularly interesting, and would be a far better solution to your problem. |
------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
