From: <fra...@de...> - 2006-05-05 13:57:39
|
Hello, Johann Borck a =E9crit : > hello again, >=20 > I would like to ask how concrete the considerations regarding an > asynchronous interface for eyedb are by now. I'm using ACE for > building an application server which is completely async, the > features of eyedb make it *the* candidate for my project, > representation and developement of argumentation for social networks, > the data-model requires tree-like structures with huge numbers of > references, on-demand loading, inheritance, possibly run-time updates > of the data-model etc., eyedb is the only open-source solution that > seems appropriate for that complexity and therefore I'm willing to > put quite some energy into an async interface, which I think, btw, > would also be a big plus for marketing eyedb. I took a look at the > client api and wonder what parts are reusable for such a subproject. > Could you maybe give me a hint where to start, what has to be > reimplemented / changed / probably discarded in order to create an > async interface? Are there any documents explaining the design of th=20 > e current interface? >=20 > meanwhile I'm using a threadpool, which works, but I have to add yet > another layer of mediating infrastructure, decoupling the server from > the blocking interface, and, if I get that right, forces me to > maintain a more or less redundant set of data-representation outside > the threadpool. To get around that I'd like to know if it is > supported to pass around the client-side database-objects i.e. from a > worker thread to the main thread, modify them, pass them back and > commit changes. my first attempts failed, any hints are appreciated > if and how this is possible. >=20 > regards, Johann >=20 Sorry for the late answer, but the question is difficult, and we had to=20 think about it carefully. First of all, IIUC, you are developping in C++? Having an async interface would be helpfull, but is quite tricky to=20 develop. Database interface are usually synchronous, probably because it=20 is easier to develop, and probably also because of the fact that the=20 underlying task (querying the db, retrieving the results) is synchronous. There are several possibilities I think: 1 - build an async interface reusing part of the code of the synchronous=20 interface, at least the RPC, and having 2 interfaces 2 - build an async interface and reuse it to build the synchronous interf= ace 3 - build an async interface on top of the current sync interface, using=20 threads In solution 1 (and in solution 2 also), you have to define a way to=20 inform the client code that the request has been executed and that for=20 instance objects can be displayed in the GUI. This can be done by=20 installing handlers that are called by the thread that reads the data=20 from the eyedb server and have it call the handler when the return value=20 of the RPC call has been received. In solution 2, the idea to build the sync interface on top of the async=20 interface would be to replace the sync RPC calls by something roughly lik= e: Status RPC_call(...) { Handler h; send_RPC_call(..., h); // async call waitForHandler( h); } This solution has the advantage of sharing a maximum amount of code, but=20 introduces a performance overhead for the sync interface. As the sync=20 interface is the most widely used, this is not necessarily a good idea. Solution 3 is a sort of the solution that you have implemented I think,=20 by using worker threads pool. However, the eyedb objects (I'm=20 considering here only the client objects) are not multi-threaded: you=20 cannot modify an object from 2 threads at the same time. My idea about this was to have a single thread that accesses the=20 database connection and to maintain a fifo of requests between this=20 thread and the main thread. When entering a request in the fifo, you can=20 enter a callback that will be called upon completion of the request.=20 This callback can 'inform' the main thread that the objects are=20 available, or that they have been updated. This can work if you are=20 building a GUI and using the MVC pattern: the Model "contains" the eyedb=20 object and the list of listeners. When the callback is called, it trigs=20 the listeners to inform them that the object has changed. However, there is an issue in this architecture: as the objects are=20 potentially accessed from 2 differents threads, there are possible=20 consistancy problems. It may be the explaination of the problem that you=20 are facing. In the model that you have implemented, do you have several threads=20 accessing the client side objects, or only 1? Be carefull that when you=20 modify a client side object by using the accessor method that are=20 provided by the C++ code generated from odl, the call of the accessor=20 method can imply a roundtrip to the server. Would it be possible to have a look at your code? Fran=E7ois --=20 Fran=E7ois D=E9chelle http://blog.dechelle.net |