Re: Cayenne 3t returning DataObjects instead of Persistent

From: Marek Wawrzyczny (marek_wawrzyczn..nternode.on.net)
Date: Tue Jan 17 2006 - 17:53:11 EST

  • Next message: Jonathan Carlson: "Re: Dynamic Data Maps"

    On Tuesday 17 January 2006 10:08, Andrus Adamchik wrote:
    > On Jan 16, 2006, at 2:06 AM, Marcin Skladaniec wrote:

    > > I have tried to use sessions to provide list of users currently
    > > logged in to server. The only data I can get on server side is from
    > > http request (host, port, username etc), service context related
    > > data like ContextObjectId, and OPPMessage data - parameters and
    > > attributes. By default OPPMessages have no attributes or params. is
    > > there a way to add some ? I thought that overriding
    > > org.objectstyle.cayenne.opp.hessian.HessianService is a good way to
    > > get more data, should I try something different ?
    >
    > Yeah, I would think that customizing the service class is the way to
    > go. Maybe at some point we'll come up with some fancy Spring-based
    > way to customize the messages on the client to pass extra info to the
    > server, but for now it seems like the most pragmatic approach should
    > be to build extra intelligence on the server end.

    I'm still to open that task in JIRA :) I didn't do that as I am not quite sure
    what we'd like to see out of this. I've been sporadically looking at the 3T
    API and code to see where and how we can hook into them. I'd like to have a
    better idea of how things glue together before I submit anything.

    Some ideas we've had floating about are:

    1) Access/login control at server end - the obvious one.
    2) Pessimistic locking at the ObjectContext level on server - imagine that
    instead of (or in conjunction with) pessimistic locking at the database level
    we would be able to lock an object on the server with enough information to
    allow the server to inform clients that there is an editing lock on that
    particular object. The server could then send information as to which client
    holds the lock.
    The object would still be available to other clients but only in a read-only
    mode.

    I'm sure we had more of these, but that's all that comes to mind now.

    Marek Wawrzyczny



    This archive was generated by hypermail 2.0.0 : Tue Jan 17 2006 - 17:53:14 EST