Get More Support

Here for you 24/7

learn more
VOD Free SDK

Start Building your Engine Now

Download Now
VOD Extranet

Access to patches, license management,
tech docs and more for existing VOD customers.

Learn More
SiteMap
Last Post 31 Jul 2006 06:21 PM by Maik Jablonski. 4 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Goran
Basic Member
Basic Member
Posts: 311


--
30 Jun 2006 10:30 PM
    Hi!

    I'm currently building a web portal application that runs on db4o. As with any portal you need to define a site map. In my wpa this is done by builing a node tree and appending content and layout information on individual nodes. When a user navigates to the portal the site map is loaded but using activation depth settings I prevent content or layout information to be loaded. This prevents the whole content of the portal to be loaded at once :). I then use navigation information from the query string to figure out which node I need to activate.
    And here is my issue. Am I right in assuming that you need to use the same client (object container) to activate the node as was used to retrieve the site map? Is there any way to overcome this? Is there an oc equivalent to object binding?

    Goran
    Maik Jablonski
    Advanced Member
    Advanced Member
    Posts: 953


    --
    05 Jul 2006 09:42 AM
    Goran:

    And here is my issue. Am I right in assuming that you need to use the same client (object container) to activate the node as was used to retrieve the site map? Is there any way to overcome this? Is there an oc equivalent to object binding?


    Hi Goran,

    as often said: best practice is to use the same ObjectContainer as long as possible.

    The typical "open-for-request-and-close-right-after"-approach works, but its a real pain (and maybe a performance killer), because you'll always need to reload objects via their ids for each request (see objectContainer.ext().getID() & objectContainer.ext().getByID(), you can also rebind objects via objectContainer.ext().bind()).

    In a typical web-application I would retrieve a objectContainer as a client from a local ObjectServer for each user and store the reference in session-scope. So every user has his own object-cache and therefore a transaction. Makes things lot easier, but memory requirements are higher than with the request-scope-approach.

    HTH, Maik
    jease.org >> Java with Ease
    Goran
    Basic Member
    Basic Member
    Posts: 311


    --
    07 Jul 2006 08:56 PM
    Thank you!
    treeder
    New Member
    New Member



    --
    31 Jul 2006 02:20 AM


    mjablonski:

    as often said: best practice is to use the same ObjectContainer as long as possible.

    The typical "open-for-request-and-close-right-after"-approach works, but its a real pain (and maybe a performance killer), because you'll always need to reload objects via their ids for each request (see objectContainer.ext().getID() & objectContainer.ext().getByID(), you can also rebind objects via objectContainer.ext().bind()).

    In a typical web-application I would retrieve a objectContainer as a client from a local ObjectServer for each user and store the reference in session-scope. So every user has his own object-cache and therefore a transaction. Makes things lot easier, but memory requirements are higher than with the request-scope-approach.

    HTH, Maik


    I have to disagree with you here Maik, although the performance might be better due to not opening and closing connections, this is a scary proposition that takes a lot more work on the app developers side since they now have to be aware that there is long running connections/transactions.  It's a common deFacto standard to use a connection-per-request (CPR) and using a connection pool with CPR should give great performance because you reuse connections and keep the total connection count down.

    Storing the connection in the user session means that you would be holding a connection open for a long period of time (30 minutes or whatever they set the session timeout to) until it can get cleaned up.  If you do hold it in the session, then you'll need to implement a Session listener to close the ObjectContainer when the session is destroyed.  And what if you have 1000 users?  You'd have 1000 open connections to the database, most of which are probably barely utilized.  

    Also, you mention that it's a pain to do connection per request, and I completely agree due to the reattaching objects issue (hopefully db4o can handle internally soon).  But after a request, you can close the connection and forget about it.

    The only reason I can think that you'd would ever really want keep an ObjectContainer open for longer than a request is if you have some kind of long transaction that cannot be commited after a single user interaction.  Even then, you might want to implement it without touching the database until the end of the conversation.
    Maik Jablonski
    Advanced Member
    Advanced Member
    Posts: 953


    --
    31 Jul 2006 06:21 PM
    Hi Travis,

    sorry, but I'm not convinced that your suggestions will scale with db4o even in a simple web-application...

    treeder:

    I have to disagree with you here Maik, although the performance might be better due to not opening and closing connections, this is a scary proposition that takes a lot more work on the app developers side since they now have to be aware that there is long running connections/transactions.


    That's the price you have to pay if you're using db4o. The application developer has to think about different issues when he is going to use db4o in a proper way, because using db4o is simply "a little bit different".

    For example: Usually a web-application developer doesn't have to think about referential integrity regarding the database. With db4o, he needs to. And there are lots of other areas where the common patterns of databased-web-application-development doesn't work out for db4o.

    treeder:

    It's a common deFacto standard to use a connection-per-request (CPR) and using a connection pool with CPR should give great performance because you reuse connections and keep the total connection count down.


    The deFacto standard is to use a RDBMS for building wep-applications. So what is the thing about deFacto standards? Maybe we have to establish different standards to make real use of db4o...

    treeder:

    Storing the connection in the user session means that you would be holding a connection open for a long period of time (30 minutes or whatever they set the session timeout to) until it can get cleaned up.  If you do hold it in the session, then you'll need to implement a Session listener to close the ObjectContainer when the session is destroyed.


    Implementing such a SessionListener is a no-brainer, isn't it? Have a look at the following article in the db4o-Knowledge-Base, which simply suggests to store an ObjectClient in the session if you can't go with sharedTransaction:

    #sharedTransaction() vs. #sessionTransaction() when working with servlets

    Maybe this article should be updated to reflect your concerns about storing an ObjectClient within a session?

    treeder:

      And what if you have 1000 users?  You'd have 1000 open connections to the database, most of which are probably barely utilized.  


    If you have 1000 users hitting your application again and again within seconds (or minutes), you'll experience lots of other problems with db4o...

    BTW: Can you explain what's the problem (in terms of costs) with open connections for a db4o-server running in "embedded" mode (with no TCP/IP involved)?

    treeder:

    The only reason I can think that you'd would ever really want keep an ObjectContainer open for longer than a request is if you have some kind of long transaction that cannot be commited after a single user interaction.


    Reusing already cached objects can be another important benefit I can think of. Utilizing more memory is a simple and cheap solution to scale an application backed by an object-database.

    Cheers, Maik
    jease.org >> Java with Ease
    You are not authorized to post a reply.


    Active Forums 4.3