This is definitely an important scenario to handle. I think initially
it should be supported as two method calls (call remote business
method, then commit and pass changes back). Eventually we will add
customizable commit hooks, so that the client wouldn't have to call a
business method, and server would decide on commit how to modify the
objects.
Andrus
On Jun 8, 2005, at 7:19 PM, Derek Rendall wrote:
> Thanks for the update.
>
> FYI: One of the reasons I wanted to play with it was to investigate
> the scenario where I make some changes to (some) data on the client,
> call a method on the server that will commit the changes AND perform
> some business logic that grabs more data, makes some associated
> changes, and commits those changes. Some of these associated objects
> MAY already be held at the client, and so any updates from the
> business method would need to be propogated back to client.
>
> For example, say I am looking at a loan statement for a client when I
> realise that the loan interest rate is incorrect. I update the loan
> interest rate and call the adjustLoanRate method in my business
> process class on the server. The server method saves the change, and
> in the same transaction adjusts any pending automatic loan payments
> (may be already viewed on client) and creates an overall loan
> adjustment (possibly only if will benefit the customer, based on fact
> its the company's fault). There could be a further ripple effect that
> the server based method makes further system requests for a client
> review by supervisory staff, automatic analysis of further potential
> cases etc.
>
> Assuming that the client holds a subset of data available in the data
> context on the server side, one possible way of handling this (and I'm
> SURE there must be better ways :-) is to pass all changed objects in
> full and only ids of unchanged objects (performance - but would it be
> a worry - or is it even necessary - can we glean this from the server
> side contents?) when making this server call. If the server updates
> any of the unchanged objects, these objects get returned from the
> method call. Similarly, the committed updates from the client also get
> returned to it. Note: this also allows the server to adjust objects as
> part of the commit process (e.g. I currently do audit trail and time
> stamp stuff this way), and the client to keep in sync with these
> changes.
>
> Is this type of scenario going to be possible, or will I have to push
> all my logic to the client, and use the server for managing data
> connections and non-transactionally important type commands/messages?
>
> Thanks
>
> Derek
>
> On 6/9/05, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
>> Hi Derek,
>>
>> After I moved past prototyping, real implementation is taking more
>> time
>> than expected. So currently 3T does't work at all. I won't attempt
>> another
>> guesstimate of when this will be in a working shape again as it'll
>> probably be wrong. But I am on it...
>>
>> Design part is mostly finished. It combines both distributed and
>> nested
>> contexts support that allowed me to simplify server-side part of
>> the stack
>> (PersistenceContext/ObjectContext pair of interfaces). Merging
>> current
>> DataContext/DataObject/DataDomain with
>> Persistent/ObjectContext/PersistenceContext is progressing pretty
>> well.
>>
>> Now the things that are not there yet... Many of the new methods
>> in the
>> stack are just placeholders and need to be impleented. Also the
>> server-side part of the ObjectContext is a DataContext subclass,
>> so once I
>> start full integration testing, I expect issues with reusing current
>> DataContext stack that expects DataObjects to be passed around.
>>
>> I'll post further updates on this list.
>>
>> Andrus
>>
>>
>>
>>
>>
>>> There seems to have been a lot of changes lately :-) and I was
>>> wondering if there was an updated version of the simple example
>>> 3T app
>>> that I could base my Eclipse RCP prototype/example on. If it
>>> exists -
>>> great (please point me at it - should get me going quicker), if
>>> not -
>>> well, I'll just try wading through the test classes to get a feel
>>> for
>>> what I need to do ...
>>>
>>> Thanks in advance for the yes or no response :-)
>>>
>>> Derek
>>>
>>
>>
>>
>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Thu Jun 09 2005 - 13:36:29 EDT