Good point. For me it was about what happens to the database if you try and
set a number to max + 1 - and the need to rollover so you don't have the "We
never expected to update this object 2**32 times!" error. Of course, I
should live so long to see that failure!
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 19, 2000 6:03 PM
To: jBoss
Subject: RE: Re[2]: [jBoss-User] Clients and Transaction Design
On Oct 19, Jay Walters quoth:
> Two common approaches are a timestamp and an ever increasing number, you
> don't need to 'generate' either you just store the last one in your entity
> and either get the current timestamp on update, or increment the number on
> update. I prefer the number one as the granularity of the system or
> database time can cause problems if it is not fine enough, but with a
number
> you have to consider getting large, or else rolling over at some point.
If all you are looking for is a "hasn't changed since I loaded the data"
type counter, even rollover isn't an issue unless you hold your
transaction open for so long the counter rolls right back to where it was.
> -----Original Message-----
> From: Ingo Bruell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, October 19, 2000 9:13 AM
> To: jBoss
> Subject: Re: Re[2]: [jBoss-User] Clients and Transaction Design
>
>
> 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]
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
--------------------------------------------------------------------------
The fact that no one understands you doesn't mean you're an artist.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
Oh no! Space monkeys are attacking! -- eddie izzard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
