On 19 Oct 00, at 12:52, Ingo Bruell wrote:
> Hi Dan,
>
> > There is no automatic time-out mechanism in J2EE that you could
> > adapt for use in a pessimistic locking scheme. One possibility
> > might be to store leasing information along with check-out
> > information. When a conflicting client tries to obtain a lock, the
> > existing lease could be examined for validity.
>
> But what happens, If the client crashes, how the stored leasing information
> would be set back ?
The lease would eventually expire.
>
> > I'm not sure what you mean by using stateful session beans to
> > organize entity beans like leased resources.
>
> I had the idea, that a client who wants writing acces to an EntityBean, get
> it from a SessionBean, who stores in an Array, which EntityBeans where
> locked. But I think this gives the same Problems like storing leasing
> information in the EntityBean, or not ?
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.
>
> > -Dan
> >
> > P.S. I probably should have mentioned before that optimistic
> > locking is generally a more favorable approach except in situations
> > where the optimism is unjustified--i.e. high contention for the same
> > data; or in situations where backing out a transaction has high
> > costs--e.g. a lot of work is done during "client think time."
>
> 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.
-Dan
>
> CU
>
> ---
> Ingo Bruell
> OBL GmbH ([EMAIL PROTECTED])
> Hude (Oldenburg)
> Germany
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
