Hi Dan,
> One problem with this approach is that session beans are intended
> for a single client only. The locking information would still need to
> be stored in a resource or component accessible from more than
> one client.
I see ...
> > Is it possible to start a transaction from the client and commit it from
the
> > client ?
>
> 1. Not portably, unless the client is also a web component or EJB
> component.
>
> 2. You should not maintain a transaction across client think time.
>
> A nice, general solution is to have a token (perhaps a counter,
> obtained from Rickard's contributed classes) as part of the entity's
> state, that is updated with each modification. When the client
> retrieves data from an entity, it also retrieves the token. When the
> client updates the data, it must also present the token--which the
> entity then checks to ensure no intervening modifications have
> occurred. This is easy to implement, and probably not too coarse-
> grained for most purposes, if you don't mind adding a field to each
> entity.
Yes, I thought about such but was thinking abaut a hashkey or somewhat.
Is the stuff from Rickard available for download ? Or how can I generate
such a token ?
I think its the best solution, because the situation that two users
(clients) change the same EntityBean is not often, I think.
CU
---
Ingo Bruell
OBL GmbH ([EMAIL PROTECTED])
Hude (Oldenburg)
Germany
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
