Remote to Local Data Service Pattern

Discussions

J2EE patterns: Remote to Local Data Service Pattern

  1. Remote to Local Data Service Pattern (6 messages)

    This pattern is described on my own site.
    Click on Patterns button at:
     
    Wave-Web Audio Visual Engineering
  2. For me it's unclear what problem this pattern tries to solve. Why one could not simply use stateful session ejbs.
    Besides I see several drawbacks in your approach:
    1. involving of two databases during the first request requeres 2PC and therefore can produce some overhead.
    2. What is a meaning of a local DB in clustered environment, or pattern should be applyied only for a sinlge box ?
    Please correct me if i am wrong.
    Alex
  3. This pattern is designed to help if you need to save a lot of user data in a session. It deals mainly with read only type data.
    Usually you would hold user session data in server memory, (part of session state) but this can lead to scalability problems.
    If you take this user data out of memory and dump it to disk via serialization you have the server affinity issue. With this you pass your user session data to a database, a developer configurable persisant session, part of which is using data taken from a remote database.

    For example:
    Say you where righting a program that used lots of customer data, (read only) and this data was split across a couple of remote databases, you wouldn't want to gather it up each time it was required, you would hold it locally. But your application was used by thousands of users and the client data was a couple of meg, your server memory would soon fill up.
    So you serialize it to disk. This ties you to a specific application server, so your clustering, scalability, failover policies won't work.

    Pushing it into a database setup and tuned to feed a client get you over this problem. Also you bundle all the data together so as you only have to look for one instance of an Entity Bean for each user to get all there customer data.

    Hope this makes sense.

    Stephen
  4. Thank you for clarification. I see your issues and almost agree. But it seems me that there are more app.servers that can gracefully handle stateful session beans scalability problem (for example: IAS, JBoss) then those supporting true 2PC, because your pattern hardly depends on XA transaction.
  5. Just curious, what application server(s) have you successfully implemented this pattern on?

    Cheers
    Adi
  6. Hi Adi,

    IBM WebSphere Application Server 3.5.3 is the test platform I am using currently......

    IBM have just released a mini version of DB2, DB2 Everyplace Version 7.2 that runs on a PDA device.

    You can find info on that here IBM DB2 Everyplace
      
    The aim to use this pattern to feed such Databases on such devices.
  7. First, many thanks to everybody who has given me feedback on this issue…………
    I am using connection pooling, the cloning function as supplied by IBM WebSphere Application
    Server and all other server benefits. These are good but do not address the issue
    I am trying to solve. The problem I am trying to address here is the problem you have when the user or application
    has a large amount of 'remote' data associated with their session/instance. This can
    be handle through a database vendor solution, (by cloning locally) but this ties you
    and probably your application to the DB vendor.
    If you code it yourself you would usually store the data either in server memory or
    persist it to disk. This gives you a server affinity issue, a big issue if you want
    scalability and fail-over.
    I want to implement a generic java based J2EE solution, database vendor independent,
    which also does away with the sever affinity issue. So:
    Application Servers like IBM WebSphere and others have persistent session support
    which you can use. This is good but it should not really be used for caching this
    type of data because large amounts of cached data that will end up slowing down the
    response time of your application, plus you have all he ins and outs associated with
    storing/retrieving it. You may ask what the user/application is doing with more than 2Mb of data in his/her
    session/instance?
    Large amounts of data are not directly part of the session/application but the session/application
    will reference what I call "Identifiable Remote Data Patterns" (IRDP's) through out
    its existence. IRDP's are what your user or application sees as blocks of "static"
    data that exist on remote database servers, blocks that may be common either across
    the whole application or common only to this user session. Lets say down the road you disperse your system.
    Some of your product information is stored on a database server in Tokyo, because
    one of your departments deals with Japan Electronics Ltd. and rather that setting
    up your own product list you go directly to Japan Electronics Ltd. Product database
    server.
    All your European customer information is stored on a database server in Amsterdam,
    because you let your European office handle mailing for the Europe, you don't want
    to clone there complete database, only take what you need.
    All your order processing is in the USA and you need information from both of the
    above sites to complete a transaction. You can identify IRDP's here.
    So let say down the road I have implemented my IRDP code as a service.
    The IRDP Service takes on the function of allowing your application server domain
    to make available, through it's EJB domain, copies of remote data.
    On start-up your application issues a request for IRDP initialization.
    The IRDP service template associated with your application connects to these remote
    sites and creates EJB instances of the required data, locally because it is in your
    application servers EJB domain. During the day you will benefit, because your application has cut down on the Remote
    Database Call Level,(RDCL).
    In the meantime you will also allow your application to maintain an up-to-date copy
    of data from JAPAN and Amsterdam because you are running the IRDP's as an "All Day
    Database Service", (ADDS), it is running in parallel with your application. One design point to note:
    If I am bringing over many rows, I don't want to. In other words I want a mechanism
    where I can compress/decompress! The IRDP template will identify these compressed
    areas to the service.
    I am getting on well with this design and will post updates on my site sometime in
    the future, WAVE.ie

    Bye,

    Steve