Discussions

Web tier: servlets, JSP, Web frameworks: Choosing DB access technology

  1. Choosing DB access technology (1 messages)

    Hi,
    I work on a kind of company internal search engine (for a construction industry IS storing news, notifications, messages, requests, documents and that kind of stuff) working with already present "legacy" Oracle9 databases in very heterogenous and for now Javaless enviroment. According to our needs and future demands, we decided to separate the application into the engine (pretty simple Struts or alike app) itself and self-standing remote adapters binded to these dbs (mapping rel. db. into objects). With this approach, we can re-use these access points in other applications later, since Java has been chosen as future platform for all development.

    The question is, which persistence technology (query management and relation/object mapping in other words) to use in those db adapters.

    Requests are: (in random order)
    - the interfaces should preferably expose plain standard packages objects, no rare framework proprietary stuff (in order to simplify future re-use by different developers without knowledge and tools of underlaying technology)
    - reasonable performance (medium loads possible)
    - the db adapter should be used without any (or with minimal) changes (preferably not the code, some descriptors at most or so) for more clients later (this is the tricky part of the design; ideal would be each client app holding own queries by itself in some nice plain simple objects keeping the adapter thin'n'clean (pooling and caching may be possible), but is this reachable with demand of performance (yes, it could parse string for every call, but this indeed is an awful bottleneck)? In the opposite case, I am afraid this adapter would be one mess in short time, if keeping track of precompiled/stored queries for more clients)
    - inserting is not needed now, but will be handy in the future
    - must be free of charge
    - in general, purpose of all this circus is to unite accessing the DB (security, manageability, ...) in the future, so the performace demand may be critical

    My feeling of candidates:
    - JDO - seems to me too bulky and complex, we don't need main advantages (binary compatibility, db independency), proven solutions are only proprietary
    - Hibernate - looks like better alternative, but still very complex
    - iBatis - looks adequate, as far as I've had a look inside
    - JDBC - the drawbacks are too much work and quite deep understanding needed to gain the performance boost over ready-to-use frameworks, but very flexible on the other hand
    - ... - ?

    As far as I know (and I know little, so please correct me if I am wrong), all of them store track of precompiled queries in them, which approach is quite inconsistent (since we need something WebServices-like, no dependency on clients). Personally, I am thinking about something like criteria object passing and assembling the query in the adapter from parametrized template.

    I am sorry for my confused views, but I would really appreciate any comment or experience with mentioned especially since this not my strong field. As well any points on the selected architecture are of high value. For now, my sympathies posses Hibernate and iBatis. If you know them, do you think they can perform well in this task?

    Thanks for any suggestions.

    Cheers,

    Oldrich
  2. Choosing DB access technology[ Go to top ]

    Hi,
    As far as I know (and I know little, so please correct me if I am wrong), all of them store track of precompiled queries in them, which approach is quite inconsistent (since we need something WebServices-like, no dependency on clients) <br>
    As far as I know Hibernate and JDO allow dynamic query. You only have to transform your criteria into an appropriate query and bind the parameters.

    Best regards, Mircea