I like your CAS4 plan to make registries responsible for cleaning
themselves.
Regarding the performance issue, what if the transaction were limited to
reading a single Ticket and deleting it if it's expired? It's OK to get
the list of Ticket IDs outside of the transactions, since IDs that were
created in between can be expired by a later clean() method, and IDs
that were deleted in between can be ignored by the current clean()
method. It's OK that this takes longer, because it's running in a
background thread and it doesn't block anything. I haven't tried this,
because I'm keeping my Tickets in memory, but it's just an idea.
Cheers,
11011011
Scott Battaglia wrote:
One of the things I've been working on with CAS4 is that Tickets, and
the items they depend on, have implementations specific to the backing
store (so that Authentication isn't lumped into a BLOB, for example).
Its actually a huge pain in the butt, and I'm not sure if its worth
the effort (for one thing, it will make us think more about what we
support since there needs to be implementations specific to each item
we support).
That clearly doesn't help CAS3 at all, and I'm mostly throwing it out
there to get feedback for CAS4 (in CAS4, registries are also
responsible for knowing how to clean themselves).
Another option, that may help with CAS3 is to encode the expiration
logic into the cleaners. Its counterintuitive, and clearly defeats
the purpose of the ExpirationPolicy. However it could be useful to do
something like "delete from serviceTicket where numberOfUses < 1 and
now() lastUpdateTime > 5000)" (I made that up right now and can't
vouch that that would actually execute). The reality is that most
people don't change the actual expiration policies, just possibly the
time limits.
Cheers,
Scott
-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
On Wed, Apr 29, 2009 at 11:38 AM, Marvin Addison
<marvin.addi...@gmail.com <mailto:marvin.addi...@gmail.com>> wrote:
> Update is only called when a ticket is acted upon (in a number
of ways).
I see, so I need the client to do something to trigger the update and
mark the ticket expired, which is the problem I'm trying to solve. I
missed that consequence in your first response. Time to consider
other options.
Thanks for taking the time to consider my proposal.
M
--
You are currently subscribed to cas-dev@lists.jasig.org
<mailto:cas-dev@lists.jasig.org> as: scott.battag...@gmail.com
<mailto:scott.battag...@gmail.com>
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to cas-dev@lists.jasig.org
<mailto:cas-dev@lists.jasig.org> as: jbeu...@hawaii.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
