You use the session id so that you don't maintain the reference to the
actual session. When the session listener sees that the session dies,
he removes all object locks for that session. Now, this still doesn't
solve the problem of one user opening multiple windows and trying to
edit the same ob
nice to know ;)
On 2/21/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote:
Andrea,
You can do this If you create a state object that has an application
scope... you can wire your session listener to it to add and remove the
session id's.
Andrea Chiumenti wrote:
> But session is user specific a
Andrea,
You can do this If you create a state object that has an application
scope... you can wire your session listener to it to add and remove the
session id's.
Andrea Chiumenti wrote:
But session is user specific and you want to lock the record accross the
application, how whould you do
But session is user specific and you want to lock the record accross the
application, how whould you do this ?
On 2/21/07, Robert Zeigler <[EMAIL PROTECTED]> wrote:
Actually, no, if the browser dies, the record won't stay locked.
The updating happens from the edit page; if the browser crashes,
To clarify, by "updating" I'm referring to the ajax notifications
that the user is still editing the object.
Robert
On Feb 21, 2007, at 2/215:50 AM , Robert Zeigler wrote:
Actually, no, if the browser dies, the record won't stay locked.
The updating happens from the edit page; if the browser
Actually, no, if the browser dies, the record won't stay locked.
The updating happens from the edit page; if the browser crashes,
there's no edit page, so no updating, so the lock expires.
Cheers,
Robert
On Feb 21, 2007, at 2/214:03 AM , Andrea Chiumenti wrote:
... But if the browser dies f
If the browser dies, then the session will timeout. The record will
not stay locked (if you just keep an in-memory record of who is
editing what). You could use a "do you want to save your changes"
notification (a la GMail and others) to either save the data or send a
request to clear the lock w
... But if the browser dies for some reason (very frequent especially with
MS products), then the record will remain locked, the only possibility with
this solution would be to add a locking timeout with application scope.
On 2/21/07, Robert Zeigler <[EMAIL PROTECTED]> wrote:
In my case, it was
In my case, it was straightforward: the user is considered to be
"still editing" if they have a browser window open to the edit page
for the object in question; if they navigate away from that page, the
system considers their edit session over.
Robert
On Feb 21, 2007, at 2/212:47 AM , Pet
Hi Robert
I like your idea, "you say that periodic ajax calls are sent to the
server to inform of the fact that the user is still editing" how exactly
do you track if a user is still editing?
Robert Zeigler wrote:
The main problem with using a session timeout for the lock is that it
doesn't
The main problem with using a session timeout for the lock is that it
doesn't allow you to detect events where a user starts to edit an
object, does not finish, but remains active in the webapp; the
session won't die, and neither will your lock. You have to
incorporate time at least to some
I don't think the benefits justify the effort involved to maintain all
those timestamps, its a bit too complex. Perhaps its better to stick to
a single table as well... rather write the session id into the database
to checkout a customer record.
Allow updates to a customer record if its not ch
Wow - what a lot of responses.
First a little more detail - use case (for example):
Take a customer record, a basic record has previously been created and the
customer has completed some forms so we are now wanting to complete all of the
details about contact information, financial details, key a
Datebase timestamp seems better than a session id. Can't get
perpetually locked and works outside a webserver session.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The suggestion of using the http session (its id actually) was pretty
cool I thought. That allows you to "timeout" the checkout/lock. You
need to make sure (as pointed out) that the locks don't get orphaned,
thereby locking everyone out of the object/record perpetually
(obviously you could write
Murray,
I also have records that need to be 'checked out' for some time and
your solution seems simple and elegant. So much so I may steal it.
I use one sequence for every primary key in the database so a table
named "lock" with
key primary key
timestamp timestamp
userid
should do it. UserId l
Leaving a database connection open for that period of time (possibly
minutes/hours) isn't advisable from what I understand.
On 2/19/07, Fred Janon <[EMAIL PROTECTED]> wrote:
Yep, SELECT for UPDATE is what's behind TRANSACTION_SERIALIZABLE...
On 2/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wr
Yep, SELECT for UPDATE is what's behind TRANSACTION_SERIALIZABLE...
On 2/20/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
How about using a SELECT . . . FOR UPDATE statement to select the record
being edited. Once you read the record it will be locked, and as long as
you keep the transact
How about using a SELECT . . . FOR UPDATE statement to select the record
being edited. Once you read the record it will be locked, and as long as
you keep the transaction open for the duration of the edit then no other
transaction will be able to select the same record for update. If the
transa
Of course this all assumes that "locking" something is a good idea at
all from a usability / scalability pov. There are rare occasions where
it's needed but I'm skeptical nonetheless...
At the very "best" you could do some kind of comet approach to letting
the user know someone else is beginning
Just use the session id and set up an HttpSessionListener to remove
user's locks when their session expires.
On 2/19/07, Luis Rodrigo Gallardo Cruz <[EMAIL PROTECTED]> wrote:
On Mon, Feb 19, 2007 at 08:17:02PM -0500, James Carman wrote:
> I would say just put a property on the object that says
On Mon, Feb 19, 2007 at 08:17:02PM -0500, James Carman wrote:
> I would say just put a property on the object that says that it has
> been "checked out" or something. That way, you can tell a user that
> tries to edit it that they can't because "so and so has this record
> checked out and is editi
I would say just put a property on the object that says that it has
been "checked out" or something. That way, you can tell a user that
tries to edit it that they can't because "so and so has this record
checked out and is editing it."
On 2/19/07, Kalle Korhonen <[EMAIL PROTECTED]> wrote:
Just
Just out of curiosity, can you tell more about your use case? I just have a
hard time believing you'd need something like this for all of your tables -
rather I'd assume it's something specific to a type of a record. And if it's
the latter, I'd just implement it in the application level along the
Interesting question! I don't have any experience in doing this but it made
me search in one of my Websphere book. Not sure if that would fulfill your
requirements but TRANSACTION_SERIALIZABLE and PessimisticUpdate-Exclusive
might be worth investigating. I am not sure what container you use and if
James Carman carmanconsulting.com> writes:
> You can use optimistic locking. When the user submits and they have
> outdated data, then you just merge the object's data with what is in
> the data store and show it back to the user for them to confirm it.
In an application where the user can spend
You can use optimistic locking. When the user submits and they have
outdated data, then you just merge the object's data with what is in
the data store and show it back to the user for them to confirm it.
On 2/19/07, Murray Collingwood <[EMAIL PROTECTED]> wrote:
Hi
Jesse Kuhnert gmail.com> wr
Hi
Jesse Kuhnert gmail.com> writes:
> hibernate.org
This is a rather simplistic answer, however I have been away and read the
documentation and am not convinced that this is providing a method that will
warn a user if somebody else if already updating a record.
Even this example of pessimistic
hibernate.org
On 2/18/07, Murray Collingwood <[EMAIL PROTECTED]> wrote:
Hi all
Many years ago I wrote a web application that utilitised a proprietary database.
The database supported record locking however it was not suitable for a web
application. So, I wrote a facility I called 'Long Locks'
29 matches
Mail list logo
