I understand the server side.
It doesn't address the client holding of the version he is looking at (the
client gets a "copy" of the values and when he comes back he needs a version
number)
but I might be missing something... :)
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
|Sent: Saturday, October 28, 2000 12:17 AM
|To: jBoss
|Subject: Re: [jBoss-User] Long-running pseudo transactions HOWTO
|
|
|Hey
|
|marc fleury wrote:
|>
|> It will be tough to provide an implementation...
|
|No, super-trivial. Just another field in the EntityBean, and a bit more
|in setData/getData. Sounds like a lot of work? Weeeell, this could be
|easily added to the EJBDoclet templates in which case it would be
|completely transparent to the bean developer: everything would be
|generated automagically!
|
|> I mean we need to keep the "id" version associated with the
|client somehow,
|> and that can only be with the proxy...
|
|Uhm.. no... reread the article.. there's an extra field in the bean and
|value objects for the version. It is very straightforward.
|
|> then we need to trap that in the client and fire an exception if
|there is a
|> version missmatch exception? as what?
|
|No, this is all done in the setData() in *the bean*. That's where the
|version is set and that's where the checking is done.
|
|/Rickard
|
|
|
|
|
|--
|--------------------------------------------------------------
|To subscribe: [EMAIL PROTECTED]
|To unsubscribe: [EMAIL PROTECTED]
|Problems?: [EMAIL PROTECTED]
|
|
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
