You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@turbine.apache.org by Steve Ruby <st...@rubysolutions.com> on 2001/03/25 00:59:58 UTC
Multiple User instances
What is the proper way to have multiple instances of a single
TurbineUser floating around at the same time?
I was under the impression that as a service TurbineSecurity
would handle multiple user instances, no?
Problem..
User logs in and the user object is placed in the session
(I'm using basicaly the standard LoginUser.java from the tdk 1a11)
Administration screen uses
TurbineSecurity.getUser(username) to get an instance of the same
user for administrative reasons,
admin sets a property of the user via setPerm and saves
the user via TurbineSecurity.saveUser(user), the database is now
updated accordingly.
Then the user logs out and their object from the session writes
over the revised user that the administrator changed.
I dont' seen an obvious way around this if it isn't handled in
turbine itself.
I'm using turbine from tdk 1a11 TurbineUser is my default user,
I only have one jdk running turbine and there is no sql
directy to the TURBINE_USER table.
Thanks for any pointers.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Multiple User instances
Posted by Rafal Krzewski <Ra...@e-point.pl>.
Steve Ruby wrote:
> admin sets a property of the user via setPerm and saves
> the user via TurbineSecurity.saveUser(user), the database is now
> updated accordingly.
>
> Then the user logs out and their object from the session writes
> over the revised user that the administrator changed.
I knew about this problem for a long time, but I didn't have time to
dig into it, as it didn't seem critical. It didn't show up until
a real administration application was created (Flux).
Greg Coladonato wrote:
> What if multiple calls to TurbineSecurity.getUser()
> returned the same instance of TurbineUser, via a
> cache? Steve, perhaps a customized subclass of
> TurbineSecurity that kept a cache on username would
> solve your problem.
That was the original solution I came up with. Please note that
BaseSecurityService uses caching mechanism for Groups/Roles/Permissions
with shared(read) and exclusive(write) methods. On the other hand
the caching mechanism for User objects would have to be more
sophisticated, and would reqire careful programing while accesing
User objects, and even more while reimplementing User interface.
Scott Anderson wrote:
> Caching the objects raises locking issues on the objects themselves if
> you don't serialize access. In other words, if two separate places get
> the same, cached object, you'll need to synchronize and/or serialize
> access to internals so you don't get two threads attempting to change
> the object at the same time. Additionally, if you don't have
> transactions on the object (I don't know how Torque et al work, being
> new to Turbine) then you could possibly interleave non-complementary
> changes from two different sources. This is bad. :-)
Exactly. I have another problem to add to the list: we would have to
implement explicit reference counting for the User instances, to
determine
when they should be removed from the cache, and their access counters
and such updated. This mechanism would be rather fragile because
programers
would have to remember about releasing User objects in the finally
clauses
every time they grab the User object from the SecurityService's cache
(we would be storing the login name instead of the User object in the
session then).
As you see, this is quite complicated, needs careful thought and depends
on the end-programers being careful. This is bad :-)
Rafal
PS. Proposals/Volunteers wellcome
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Multiple User instances
Posted by Daniel Rall <dl...@collab.net>.
Greg Coladonato <gc...@yahoo.com> writes:
> What if multiple calls to TurbineSecurity.getUser()
> returned the same instance of TurbineUser, via a
> cache? Steve, perhaps a customized subclass of
> TurbineSecurity that kept a cache on username would
> solve your problem.
>
> Greg
We do this is Helm with a Map that keeps the mostly commonly used
objects in memory:
http://helm.tigris.org/source/browse/helm/java/org/tigris/helm/tool/BufferCache.java?rev=1&content-type=text/x-cvsweb-markup
http://helm.tigris.org/source/browse/helm/java/org/tigris/helm/tool/SequencedHashtable.java?rev=1.5&content-type=text/x-cvsweb-markup
The cached object must be removed from cache in a synchronous fashion
whenever an edit to the object occurs. Even then, there is the slight
possiblity of stale objects. This only works so simply in a single JVM
scenario.
Daniel Rall <dl...@collab.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Multiple User instances
Posted by Greg Coladonato <gc...@yahoo.com>.
--- Jon Stevens <jo...@latchkey.com> wrote:
> on 3/24/01 4:15 PM, "Steve Ruby"
> <st...@rubysolutions.com> wrote:
>
> > I'm not modifying the objectData, I'm modifying a
> real column.
>
> Ah. I see...
>
> > For example
> > if the administrator has the ability to reset the
> users password using
> > forcePassword(), I get the same result.
>
> Yes, there is a locking contention there.
>
> In other words, there are two TurbineUser objects
> floating around...
>
> > actually the values I'm using setPerm on are not
> in the object data but
> > real columns that are being accessed via setPerm
> (they were added to
> > a new map).
>
> Kewl.
>
> > Should admin be able to set non objectData values
> while the user is logged in?
> > Your message seems to indicate that the problem
> would only exist for
> > values in objectData, but that isn't the case
> here.
>
> You are right, it is a more global issue and I
> hinted at that in my last
> posting. This goes beyond TurbineUser and into
> overall application
> design...ie:
>
> Two objects in JVM heap that point to the same row
> in a database. First one
> gets written and the second one overwrites the
> first. How do you deal with
> that issue? You can perform row level locking on the
> objects through the use
> of last modified timestamp checking.
What if multiple calls to TurbineSecurity.getUser()
returned the same instance of TurbineUser, via a
cache? Steve, perhaps a customized subclass of
TurbineSecurity that kept a cache on username would
solve your problem.
Greg
> When doing a write to the database, you first check
> to see if the last
> modified of the row is > the last modified of the
> object you are about to
> write. If the condition is true, then you can
> essentially ask the user to
> re-create what they are working on or overwrite the
> existing entries...
>
> "Sorry, the object you are attempting to modify has
> already been modified by
> another process. Would you like to start over or
> overwrite the existing
> entry?"
>
> -jon
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-user-help@jakarta.apache.org
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Multiple User instances
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/24/01 4:15 PM, "Steve Ruby" <st...@rubysolutions.com> wrote:
> I'm not modifying the objectData, I'm modifying a real column.
Ah. I see...
> For example
> if the administrator has the ability to reset the users password using
> forcePassword(), I get the same result.
Yes, there is a locking contention there.
In other words, there are two TurbineUser objects floating around...
> actually the values I'm using setPerm on are not in the object data but
> real columns that are being accessed via setPerm (they were added to
> a new map).
Kewl.
> Should admin be able to set non objectData values while the user is logged in?
> Your message seems to indicate that the problem would only exist for
> values in objectData, but that isn't the case here.
You are right, it is a more global issue and I hinted at that in my last
posting. This goes beyond TurbineUser and into overall application
design...ie:
Two objects in JVM heap that point to the same row in a database. First one
gets written and the second one overwrites the first. How do you deal with
that issue? You can perform row level locking on the objects through the use
of last modified timestamp checking.
When doing a write to the database, you first check to see if the last
modified of the row is > the last modified of the object you are about to
write. If the condition is true, then you can essentially ask the user to
re-create what they are working on or overwrite the existing entries...
"Sorry, the object you are attempting to modify has already been modified by
another process. Would you like to start over or overwrite the existing
entry?"
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Multiple User instances
Posted by Steve Ruby <st...@rubysolutions.com>.
Jon Stevens wrote:
>
> on 3/24/01 3:59 PM, "Steve Ruby" <st...@rubysolutions.com> wrote:
>
> > Problem..
> >
> > User logs in and the user object is placed in the session
> > (I'm using basicaly the standard LoginUser.java from the tdk 1a11)
> >
> >
> > Administration screen uses
> > TurbineSecurity.getUser(username) to get an instance of the same
> > user for administrative reasons,
> >
> > admin sets a property of the user via setPerm and saves
> > the user via TurbineSecurity.saveUser(user), the database is now
> > updated accordingly.
> >
> > Then the user logs out and their object from the session writes
> > over the revised user that the administrator changed.
> >
> > I dont' seen an obvious way around this if it isn't handled in
> > turbine itself.
>
> Good one! :-)
>
> There are two somewhat solutions:
>
> #1. The Admin function does not save/modify the objectData
>
> #2. The user's objectData can have a last modified stamp associated to
> it. When the user logs out, this timestamp is checked for what is in the
> database. If the last modified is less than the one in the database, then
> handle the issue gracefully somehow (ie: the two hashtables are combined, an
> error is reported or something).
>
> Personally, I don't think that the admin function should be modifying the
> users objectData at all. If there is something in objectData that an admin
> might need to modify, then it should be added as a real column to the
> turbine_user table instead of being stored in the objectData so that shared
> accesses can be a database level locking.
>
> thanks,
>
> -jon
>
I'm not modifying the objectData, I'm modifying a real column. For example
if the administrator has the ability to reset the users password using
forcePassword(), I get the same result.
actually the values I'm using setPerm on are not in the object data but
real columns that are being accessed via setPerm (they were added to
a new map).
Should admin be able to set non objectData values while the user is logged in?
Your message seems to indicate that the problem would only exist for
values in objectData, but that isn't the case here.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org
Re: Multiple User instances
Posted by Jon Stevens <jo...@latchkey.com>.
on 3/24/01 3:59 PM, "Steve Ruby" <st...@rubysolutions.com> wrote:
> Problem..
>
> User logs in and the user object is placed in the session
> (I'm using basicaly the standard LoginUser.java from the tdk 1a11)
>
>
> Administration screen uses
> TurbineSecurity.getUser(username) to get an instance of the same
> user for administrative reasons,
>
> admin sets a property of the user via setPerm and saves
> the user via TurbineSecurity.saveUser(user), the database is now
> updated accordingly.
>
> Then the user logs out and their object from the session writes
> over the revised user that the administrator changed.
>
> I dont' seen an obvious way around this if it isn't handled in
> turbine itself.
Good one! :-)
There are two somewhat solutions:
#1. The Admin function does not save/modify the objectData
#2. The user's objectData can have a last modified stamp associated to
it. When the user logs out, this timestamp is checked for what is in the
database. If the last modified is less than the one in the database, then
handle the issue gracefully somehow (ie: the two hashtables are combined, an
error is reported or something).
Personally, I don't think that the admin function should be modifying the
users objectData at all. If there is something in objectData that an admin
might need to modify, then it should be added as a real column to the
turbine_user table instead of being stored in the objectData so that shared
accesses can be a database level locking.
thanks,
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-user-help@jakarta.apache.org