Home Help Center

ICE and DB ORMapper

In reviewing of some latest OR Mapper/DB layer open source project, Hibernate, iBatis both look very promising, there seems to be some other light container development going in the meantime.

However, in a nutshell, will ICE be integrated with any of these OR mapper without major hurdle?

An example is, client application code contact the db layer, in this case the Hibernate code to handle the data persistence, which is totally hidden to the application. To the application code, there is no difference if the Hibernate layer persist the data to a local database or a remote data store.

In case the data storage is located remotely. I assume the Hibernate db layer would contact ICE layer to pass its object to the server side, where the ICE skeleton would pass the object to another Hibernate layer (in exactly the same class graph) on the server side which directly connects to the database to resovle OR mapping and persistence.

Does this scenario make sense? Thanks.

Comments

  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Yes, this scenario makes sense.
    Obviously Hibernate would need to use Ice (implement an Ice server and client) to transport its persistent objects "over Ice".

    I know very little about Hibernate, so I have no idea how easy or difficult it would be to rewrite Hibernate's "network layer" (assuming it already has one) using Ice.

    Cheers,
    Bernard
  • In a revisiting of this subject, it's found that Hibernate doesn't have a flexible layered architecture that allows easy decoupling and utilize ice network transport layer.

    Alternatively, client data can be temporarily persisted as xml (also serve as disk caching to avoid round trip), then in a manner of messaging queue process, the xml data is passed to ice client code, where it gets send to ice server side and later written to db.

    In this puzzle, there are codes to be written to
    1. persist object to xml,
    2. messaging queue the xml to send to ice client side.

    The question is: can ice client (not the full server code) handle these above two tasks so no code need to be written? In another word, can ice client side work as a guaranteed messaging queue (including object persistence to xml or any form).

    Thanks.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    With Ice, it would make more sense to cache the persistent objects on the client side as Ice class objects, and use Ice to pass these class objects from the server to the client and back (when modified).

    You could also stream XML if you prefer, although Ice provides no particular support for "XML on the wire". In either case, you will need to write some code.

    > can ice client side work as a guaranteed messaging queue

    It depends what you mean by "guaranteed". With TCP, Ice guarantees at most once semantics (see Ice book 1.5.1 p14). If a non-idempotent request succeeds, you know it was executed exactly once.

    Cheers,
    Bernard
  • Thanks bernard for the reply.

    To cache the data either in ice object form or xml client side, not limited by cached in memory. The goal of this caching is mostly to avoid unnecessary trip to server side, such if the data is already at client then use it, so frenquently visited data may be kept at client for a long period of time. thus, this cache is most likely in a form of persistence at client disk. For this reason, I am not sure if ice object can be persisted directly or has to be streamed to xml/text file?

    What I mean "guaranteed" messaging delivery is also related to the above disk caching, as this piece of data can be deliever to server side upon modified, in case lost, the client side still have the disk copy of that data.

    However, here is the question if I need to rephrase it, does ice on the client side allow me to cache the ice object at as needed basis, where caching is based on frequencey of the requests for the ice object. Second, does ice at client side support some type of messaging queue to deliver modified object data to server?

    In this case, my client application can request data from ice (client) and hand the modified data to ice (client) so be totally hidden for how ice will process the data. Therefore ice client should retain a local caching of some most used objects while deliever data to server in an asynchronous manner (queued) for server scalability.
  • dragzhbdragzhb Member ✭✭
    I think the idea is good, I will try to develop this project.
    In server use Hibernate to implement O/R Map ,client use Ice client to invoke database data.
  • Originally posted by bernard
    With Ice, it would make more sense to cache the persistent objects on the client side as Ice class objects, and use Ice to pass these class objects from the server to the client and back (when modified).

    Bernard

    Could you elaborate how a object can be persisted as ice object? Assumed ice client side is only a library, doesn't have berkeley db installed, doesn't the ice object persistence utilize some disk file form?
  • dragzhbdragzhb Member ✭✭
    First you must use class to define data in Ice
    Second Ice Server must use Java and hibernate to implement DB Persistent.

    then you can define interface like Hibernate to wrap hibernate function,
    example :

    interface db
    {
    insert(Ice::Object obj);
    update(Ice::Object obj);
    findby(sqlwhere)
    }

    I think like this,it's difficult in define class. if we solve that , I think all Ice client can implement O/R map
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Originally posted by RusselHarvey

    However, here is the question if I need to rephrase it, does ice on the client side allow me to cache the ice object at as needed basis, where caching is based on frequencey of the requests for the ice object. Second, does ice at client side support some type of messaging queue to deliver modified object data to server?

    Ice does not provide any form of object-caching on the client side: you would need to choose a caching strategy, and use Ice features (class objects, synchronous and/or asynchronous requests) to implement it.

    If many threads use your object cache concurrently, I recommend you look at the IceUtil::Cache helper class. Its main purpose is to allow concurrent lookups and object-loading in a cache.

    Cheers,
    Bernard
  • Originally posted by bernard
    Ice does not provide any form of object-caching on the client side: you would need to choose a caching strategy, and use Ice features (class objects, synchronous and/or asynchronous requests) to implement it.

    If many threads use your object cache concurrently, I recommend you look at the IceUtil::Cache helper class. Its main purpose is to allow concurrent lookups and object-loading in a cache.

    Cheers,
    Bernard

    Would you recommend any object-caching method, I can only think of xml (de)serialization though heard very slow.

    You didn't mention if ice client piece has any support of a messaging queue (given no berkeley db/ice freeze required at client)?

    Thanks.
  • bernardbernard Jupiter, FLAdministrators, ZeroC Staff Bernard NormierOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Would you recommend any object-caching method, I can only think of xml (de)serialization though heard very slow.

    Often a client would only cache objects in memory (maybe using virtual memory), so no disk-storage issue. But if you want to store your client cache on disk, you should consider using Freeze: it's the easiest way to serialize your Ice objects to files.

    The next Ice version will also include a public API to serialize/deserialize Ice objects using the Ice encoding: see http://www.zeroc.com/vbulletin/showthread.php?s=&threadid=785.
    You didn't mention if ice client piece has any support of a messaging queue (given no berkeley db/ice freeze required at client)?

    If you mean a reliable queueing system -- where messages are stored persistently and delivered later to the server if it's down when you send -- then no, Ice does not provide such service.

    Cheers,
    Bernard
Sign In or Register to comment.