►
Description
Speaker: Les Hazlewood, Co-Founder & CTO of Stormpath and Apache Shiro PMC Chair
Slides: http://www.slideshare.net/planetcassandra/infinite-sessionclusteringwithapacheshiro9x16-23252714
In this session Les Hazlewood, the Apache Shiro PMC Chair, will cover Shiro's enterprise session management capabilities, how it can be used across any application (not just web or JEE applications) and how to use Cassandra as Shiro's session store, enabling a distributed session cluster supporting hundreds of thousands or even millions of concurrent sessions. As a working example, Les will show how to set up a session cluster in under 10 minutes using Cassandra. If you need to scale user session load, you won't want to miss this!
A
My
name
is
les
hazlewood,
I'm
the
apache
shiro
pmc,
chair,
apache
shiro
is
a
security
framework
for
java
applications.
It
goes
inside
of
your
app
and
you
use
it
to
secure
pretty
much
all
aspects
of
your
application,
I'm
also
the
cto
of
stormpath.
We
are
an
identity,
management,
sas
or
fundamentally
arrest,
json
api
that
automates
authentication
and
access
control
for
developers,
building
apps.
So
all
of
the
difficulties
with
attack
breaches
with
accounts
and
password
storage
and
things
that
have
other
larger
companies
have
suffered
this
year.
A
We
solve
that
problem
and
also
offload
a
lot
of
the
development
effort,
so
you
don't
have
to
worry
about
building
this
stuff
anymore.
So
that's
what
we
do,
as
I
mentioned,
shear
is
a
security
framework
or
apache
top-level
project
shiro.apache.org,
and
the
basic
principle
of
the
framework,
more
than
anything
else,
is
to
keep
things
very
simple,
easy
to
understand
and
allow
people
to
get
up
and
running
quickly
securing
their
applications.
A
Shiro
does
a
lot
of
things
it's
built
on
what
what
the
shiro
team
calls
the
four
cornerstones
of
application
security
and
that's
authentication,
author
authorization,
cryptography
and
session
management-
we're
just
going
to
be
talking
about
the
session
management
features
of
shiro
today.
How
many
people
here
are
familiar
with
shiro
or
have
used
it
or
at
least
know
what
it
is?
Can
I
get
a
show
hands?
A
Just
some
some
kind
of
quick
review,
though
shiro
is
based
around
this
notion
of
a
subject
and
this
if
you're
familiar
with
josh
or
the
java
security
model.
This
is
not
the
jaws
subject.
This
is
shiro's
own
interface
or
representation
of
it,
and
the
subject
basically
represents
the
currently
executing
user,
and
one
of
the
foundational
principles
of
shiro
is
that
shiro
should
work
in
every
environment,
not
just
web
environments.
So
this
this
call
will
work
in
a
web
application
or
work
on
a
command
line.
Application
will
work
in
a
server
it'll
work.
A
You
know
doing
some
work
right
now
incorporating
shiro
inside
of
cassandra.
It
works
inside
of
activemq.
The
idea
is
that
this
works
anywhere
and
once
you
acquire
the
currently
executing
subject,
you
can
do
all
sorts
of
security
operations
like
logging
in
doing
access,
control
checks
like
whether
they're
permitted
to
do
something
or
not
or
whether
or
not
they
have
a
particular
role.
A
That
is
the
core
of
shiro's
kind
of
api
from
a
an
end
user
developer
perspective,
but
let's
drill
down
into
session
management
features
of
the
subject
session
management,
as
as
you
might
expect,
it's
a
temporal
data
context
associated
with
a
specific
application
user,
the
person
using
the
application
and
so
session
management's
managing
that
life
cycle.
And
it's
exactly
what
you're
used
to
you
know:
http
based
applications
have
sessions.
That's
that's
what
we're
talking
about
shiro's
features.
We
support
heterogeneous
access,
meaning
you
can
have
a
java
client
and
a
ruby
client
and
a
command
line.
A
Client
and
a
web
application.
Client
I'll,
be
talking
to
and
using
the
same
http
session,
which
is
traditionally
usually
limited
to
a
particular
client,
but
for
advanced
use
case
scenarios
like
maybe
your
desktop
user
interface,
is
in
sync
with
the
web
application
that's
possible
with
shiro
everything
in
it
is
pojo
based.
So
it's
very
simple
to
use.
We
have
you
know
pojo
accessories
and
setters
for
everything.
That's
configurable
in
the
project,
there's
no
special
or
crazy
apis,
there's
an
event
listener
construct.
So
you
can
listen
for
interesting
events.
A
You
know
when
the
session's
expired
when
it's
been
deleted
or
when
it's
been
created.
We
also
retain
the
host
address
from
where
the
session
was
initiated.
So
you
can
leverage
the
host
address
for
cert
certain
security
policies.
It's
only
recommended
to
do
that
in
internet
environments
because
with
http
proxies
and
and
caching
servers,
and
why
not
ip
addresses
and
hostnames
are
not
that
reliable
outside
of
the
internet
and
we
of
support,
inactivity
and
expiration
support.
A
So
this
particular
use
case
is
if
you're,
building
a
rich
client
application
and
maybe
you're
interacting
with
that
rich
client
app
for
30
minutes
or
more,
maybe
it's
a
graphics,
editing
program
or
whatever,
but
if
you're
not
actively
communicating
with
the
server
the
server
will
time
out
the
session.
So
shiro
supports
this
touch
mechanism
that
allows
you
to
keep
the
session
alive
for
as
long
as
the
user's
using
the
app
and
it's
transparent
in
web
use
for
java
apps.
So
you
can
interact
with
the
normal
server
request.
A
Api,
the
normal
http
session
api
and
ensureo
will
will
honor
those
those
api
calls.
So
that
means
you
don't
have
to
change
existing
code
to
leverage
shiro
and
one
of
the
biggest
things
about
shiro's
session
infrastructure.
And
what
we'll
be
talking
about
today
is
it
provides
container
independent
clustering.
So
if
you
try
to
cluster
on
jetty
and
you
try
to
cluster
sessions
on
tomcat
or
jboss
or
geronimo,
what
have
you
every
each
one
of
those
containers?
Does
it
slightly
different
with
shiro?
You
can
do
this
once
and
it's
portable
across
every
application.
A
So
that's
that's
one
of
the
big
draws
to
why
you
might
want
to
use
that.
So
this
is
how
you
get
a
session.
You
get
the
access
to
the
current
subject
and
just
like
the
servlet
request
api,
you
can
either
pass
in
a
boolean
or
not
to
indicate
whether
or
not
the
session
should
be
created
or
not.
So
the
first
call
guarantees
that
a
session
exists.
A
The
second
one
gets
it
if,
if
it
exists
and
if
it
doesn't
exist,
it
returns
null
so
kind
of
what
you're
familiar
with
with
the
servlet
request
api
and
the
session
has
a
number
of
methods
on
it
that
you
would
expect
again.
These
are
very
similar
to
the
http
servlet
request,
api
or
excuse
me,
the
http
session
api.
A
You
can
get
set
attributes
there's
this
additional
touch,
message
method
that
I
mentioned,
but
no
no
surprises
here,
but
let's,
let's
drill
down
into
how
this
works
within
shiro's
code
base.
So
you
can
see
how
sessions
interact
with
the
framework
as
well
as
interact
with
the
data
store.
So
when
you
call
getsession
it
gives
you
an
object,
a
session
object,
which
is
an
interface
and
in
reality
this
is
a
proxy,
not
a
java,
runtime
aop
proxy.
It's
an
actual.
A
You
know
java,
based
code
level
proxy,
that
proxy
is
a
session
manager
and
any
interaction
that
you
have
with
a
session
actually
delegates
to
the
underlying
session
manager.
Who's
responsible
for
you
know
making
sure
that
everything's
working
correctly,
the
session
manager
in
turn,
has
a
session
factory
that
it
can
use
and
the
session
factory
is,
is
used
to
create
brand
new
session
objects
as
they're
required,
and
so
you
might
get
a
session
factory,
creating
an
object
and
then
going
up
the
chain.
A
A
There
is
a
session
cache
that
can
be
leveraged
to
ensure
that
you're
constantly
referencing
the
session
in
memory,
and
you
don't
have
to
necessarily
go
to
disk
or
go
to
the
network
every
time
and
then.
Finally,
this
is
the
data
store,
and
that's
really.
What
we're
going
to
be
talking
about
here
today
is
using
cassandra
as
that
data
store.
A
We're
going
to
talk
about
session
dao
the
session
or
the
data
store
session
id
generator
and
we'll
talk
a
little
bit
about
the
session
validation
scheduler
as
it
pertains
to
cassandra
or
as
you'll
see
as
it
might
not
pertain
to
cassandra.
So
let
me
show
you
really
briefly
what
web
config
looks
like
for
shiro.
So,
if
you're
setting
up
shiro
in
a
project,
it's
really
simple,
there's
only
two
lines
or
excuse
me,
two
or
actually
there's
three
major
parts
in
the
web:
xml
config.
A
You
set
up
this
listener,
which
will
build
up
the
shiro
environment
and
its
respective
components
and
then
there's
a
shiro
filter
that
will
filter
all
web
requests
going
into
the
web
application.
To
ensure
that
you
know
the
users
may
be
authenticated
to
access
a
particular
url
or
they're,
maybe
trying
to
access
a
particular
rest
resource.
The
filter
will
intercept
all
the
requests
of
the
web
app
and
make
certain
security
or
policy
decisions
based
on
configuration,
and
so
the
the
pa,
the
the
corresponding
part
of
that
config
is.
A
A
So
this
is
just
getting
shiro
set
up
in
web
and
sorry
in
web.xml,
but
the
meat,
the
core
of
shiro's
config,
is
typically
done
by
some
other
config
mechanism.
It
can
either
be
spring
xml
or
some
xml
format
you
define
shiro's
default,
though,
has
a
kind
of
out
of
the
box,
lowest
common
denominator,
ini
based
configuration
that
allows
you
to
basically
do
quite
a
bit
with
it
with
with
kind
of
limited
resources.
A
The
idea
here
is
that,
in
the
main
section
you
can
define
object
graphs
by
using
object,
graph
kind
of
definition,
language.
You
know
basically
traversing
properties
and
setting
values.
That's
really.
I
call
it
like
poor
man's
dependency
injection,
it's
basically
very
similar
to
spring
and
juice,
just
done
in
an
ini
format.
A
Users
and
roles
are
optional
for
statically,
defined
definitions
of
users
and
roles
and
permissions.
Of
course,
shiro
supports
a
whole
number
of
different
data
sources
and
gde
and
active
directory,
and
things
like
that
to
to
get
this
information
and
then
the
urls
is
how
you
define
filters,
but
we're
not
going
to
really
talk
about
the
bottom.
Three
we're
just
going
to
show.
You
show
you
how
to
set
up
session
clustering
using
that
main
session.
A
A
It's
really
just
a
dao
that
delegates
all
its
corrupt
operations
to
a
distributed,
enterprise,
cache
like
terra,
cotta
or
eh,
cache
or
hazelcast,
or
you
know,
gigaspaces
or
whatever
any
of
these
enterprise
caches
can
be
used
to
store
your
sessions.
But
in
this
presentation
we're
not
going
to
do
that
right.
We're
going
to
keep
all
of
our
data
in
a
database
or
data
store
that
we're
already
using
so
assuming
that
you're
using
cassandra
we
can.
We
can
use
cassandra
for
everything,
so
we
don't
need
this.
A
We
don't
have
to
worry
about
the
session
manager
or
the
session
cache
we're
actually
going
to
avoid
using
a
cache
entirely
because
sandra's
actually
plenty
fast
to
handle
these
things
on
its
own,
without
the
need
of
an
intermediate
cache
like
a
like
a
memcache
or
something
like
that.
It's
blazingly
fast,
and
there
are
techniques
that
we
can
do
to
keep
this
fast.
So
you
don't
need
additional
infrastructure,
which
is
part
of
the
draw.
I
think
for
using
cassandra
for
session
caches
or
excuse
me
for
a
session
store.
A
We
will
set
up
a
new
session
id
generator,
though
in
this
case
we're
going
to
generate
time-based
uuids,
just
as
a
matter
of
course
they
can
be
used
in
case
you
wanted
to
store
other
kind
of
tables,
or
you
know,
column
families
for
information
that
you
care
about.
You
can
do
things
in
sorting
techniques
and
range
queries,
so
we'll
set
up
a
session
id
generator
and
then
finally,
we'll
use
cassandra
as
the
data
store.
A
So
there's
two
approaches:
we
can
either
subclass
the
abstract
session
dao
and
shiro,
or
we
can
extend
the
caching
one,
as
I
said,
the
caching
one
kind
of
enables
right
through
caching.
We
don't
really
need
that
with
cassandra,
so
we're
gonna
go
with
the
top
approach,
where
we
implement
that
particular
api
to
do
what
we
need
to
do
so.
A
The
first
thing
to
do
is
in
the
main
section
we're
going
to
configure
shiro's
native
session
manager,
and
this
is
necessary
because
by
default,
shiro
will
use
the
servlet
container
that
it's
deployed
in
as
the
servlet
container
session
manager,
so
the
serverless
container
in
what
you're
used
to
you
know,
maybe
tomcat's
implementation
is
what
shiro
delegates
to
by
default.
There's
nothing
you
have
to
do.
But
if
we're
going
to
do
native
session
management
or
you're
relying
on
shiro
to
implement
the
servlet
api
essentially
or
the
session
api,
we
have
to
set
up
a
native
one.
A
So
we're
going
to
create
a
native
one,
and
this
is
simple
enough
to
read.
As
you
might
expect.
The
first
line
creates
a
new
instance
and
the
second
line
assigns
the
session
manager
to
the
security
manager,
security
manager,
shiro's
kind
of
root
level
construct
in
config,
and
so
we've
defined
our
native
session
manager.
Now
we're
going
to
actually
assign
a
an
implementation
of
a
session
dao
that
that
is
specific
to
cassandra
and
I'll
show
you
some
of
the
implementation
details
for
this
as
we
move
on.
A
But
the
idea
is
that
I
created
a
shiro
specific
cluster
factory
and
all
that
is
in
shiro.
Speak
is
just
an
object.
That
returns
some
other
object.
In
this
case.
This
object
is
responsible
for
acquiring
acquiring
a
a
cluster
object
and
I'm
using
in
this
case
datastax's
native
java
driver,
and
they
have
a
cluster
object
in
their
java
driver
api.
A
And
so
all
this
thing
does
is
create
that
cluster
object
to
to
point
to
a
particular
cassandra
cluster.
In
this
case,
I'm
defaulting
to
localhost,
there's
no
additional
config
necessary
and
then
once
I
have
the
cluster,
I'm
going
to
create
this
cassandra
session.
Dio
I'm
going
to
inject
the
cluster,
so
it
can
use
it
to
interact
with
the
cluster
and
then
there's
a
couple.
A
A
We've
got
our
primary
key,
which
is
the
uuid,
and
we've
got
some
additional
properties,
the
start
time
stamp
when
it
was
started,
the
stop
time
stamp.
If
the
session
stopped
and
persisted
back
to
the
data
store.
This
will
tell
this
will
tell
you
when
it
was
stopped.
The
last
access
time
is
really
important.
Anytime,
a
request
comes
into
the
web
server.
We
have
to
update
the
last
access
timestamp
to
effectively
handle
timeout
policies.
A
And
finally,
we
have
a
serialized
blob
value
and
the
idea
is
that
in
shiro,
when
we
persist
a
session
object
again,
it's
just
a
pojo
under
the
hood
when
we
persist
it
we're
actually
going
to
serialize
it
and
shiro's
default
session.
Implementation
uses
a
very
efficient
serialization
mechanism
with
bit
masks
to
only
store
data
that
needs
to
be
stored,
not
not
necessarily
the
entire
graph.
A
So
this
is
more
efficient
than
just
normal
native
java
serialization.
But
the
idea
is
that
when
we
store
it
to
cassandra,
we
want
to
store
it
in
the
serialized
value
blob
and
then,
when
we
get
it
back
from
cassandra,
we
just
deserialize
it
and
then
use
it
within
the
container.
So
no
no
surprises
here.
A
One
of
the
interesting
things
I
need
to
point
out,
though,
is
that
all
shiro
needs
is
the
serialized
value
and,
of
course,
the
id
you
know
we
do
lookups
by
id,
and
it
really
lends
itself
well
to
cassandra's
architecture,
because
shiro
by
default
doesn't
need
to
support
any
kind
of
querying
mechanism
it's
just
as
for
given
an
id.
Maybe
that
comes
in
as
a
session
id
cookie
or
a
j
session
id
request
parameter,
go
ahead
and
acquire
the
session
for
me
corresponding
to
this
id
there's.
A
A
The
other
values
in
this
table
are
really
there
for
kind
of
query
convenience.
If
you
do
queries
on
the
table-
and
you
want
to
see
this
information-
it's
there
for
you
to
visualize
it,
but
shiro
doesn't
need
it,
but
I
included
it
just
because
it's
convenient
it's
really,
not
that
much
much
extra
data
and
it's
useful
in
debugging
or
if
you
need
to
interact
with
the
with
the
table.
A
But
what
about
the
session
validation?
Scheduler?
You
know
I
mentioned
before
you
have
to
use
a
scheduler
to
make
sure
that
or
session
orphans
don't
fill
up
the
data
store
over
time
and
and
the
simple
answer.
That
is
that
we
can.
We
can
leverage,
cassandra's,
ttl
functionality
to
auto
expire,
auto
remove
data.
That's
that's
in
cassandra,
and
this
is
really
convenient
because,
because
the
nodes
in
your
web
architecture
that
have
or
reference
sessions
don't
need
to
run
a
scheduler
on
each
node,
you
don't
have
to
coordinate
schedule
scheduling
between
nodes.
A
You
can
just
rely
on
the
data
store
to
take
care
of
this
auto
delete
functionality
when
the
session
is
expired,
so
because
we
don't
need
to
use
a
scheduler
we'll
tell
shiro
just
to
turn
that
off.
So
in
this
case,
by
default
session,
validation
is
enabled
and
it
should
be
to
prevent
orphans,
but
we're
going
to
tell
shiro
not
to
worry
about
it
because
cassandra's
got
us
covered,
and
this
is
what
it
looks
like
when
we
actually
want
to
store
the
data
into
cassandra
again.
A
This
is
sql3
cql3
syntax
and
we
execute
these
statements
via
the
java
driver.
In
the
in
the
code
base,
but
the
idea
here
is
is
that,
if
you,
if
you
may
or
may
not
know
but
cassandra
an
insert
and
an
upser
or
excuse
me
insert
an
update,
are
effectively
the
same
thing
when
you're
referencing
the
same
primary
key,
you
don't
have
to
insert
something
first
and
then
update
it
later.
You
can
use
the
exact
same
query
to
do
both
operations,
so
it's
effectively
a
save
operation
regardless
if
it
exists
or
not.
A
A
Timeout
is
my
own
reference
by
the
way,
that's
not
part
of
cql,
it's
just
an
indi,
a
visual
indicator
to
say
that
whatever
that
timeout
value
is
for
that
particular
session,
you
should
you
should
set
it
there,
so
that
the
ttl
value
is
set
for
all
those
columns
and
so
we're
just
updating
the
values
and
the
serialized
value
where
id
equals.
Whatever
our
time,
uid
is
so
very
simple
insert
what
about
tombstones?
You
know
this
is
probably
the
biggest
one
of
the
biggest
concerns
about
cassandra.
A
Is
I'm
deleting
things
and
sessions
auto
expire
that
will
there?
You
know
it's
going
to
leave
tombstones
when
that
information
is
deleted.
Clearly
sessions
are
temporal
or
transient,
so
they
might
exist
for
30
minutes
and
then
should
be
removed
or
disappear
altogether,
and
the
answer
is
that
that
is
true.
All
of
this
is
true,
and
you
do
need
to
be
aware
of
tombstones.
A
You
need
to
make
sure
they
don't
fill
up
your
data
store,
and
so,
after
talking
to
various
cassandra
experts,
it
was
highly
recommended
that
the
gc
grace
for
this
particular
column
family,
is
probably
no
more
than
a
day.
I've
even
heard
recommendations
from
some
of
the
experts
on
you
know
maybe
set
it
to
zero
to
let
cassandra
clean
this
stuff
up
whenever
it
needs
to,
and
this
is
really
going
to
be
dependent
upon
your
performance
profile
and
your
characteristics
for
your
application.
A
So
if
you
have
just
kind
of
a
few
odd
sessions
throughout
the
day-
and
I
mean
even
if
it's
thousands
or
even
hundreds
of
thousands-
it's
not
really
going
to
fill
up
your
data
store
that
much
the
amount
of
data
in
a
session
is
typically
pretty
low,
and
so
you
can
maybe
delay
it
or
just
have
your
gc
grace
to
just
be
a
single
day,
and
that
might
be
good
enough.
You
know
10
days.
The
default
is
probably
way
too
much.
A
You
know
it
will
fill
up
your
data
store
over
time
and
then
also
they
recommended
compaction.
You
know,
sessions
are
kind
of
temporal,
and
so
you
could
have
a
compaction
strategy
that
kind
of
reflects
the
duration
that
those
things
are
allowed
to
to
live
and
to
exist.
So
by
using
a
level
compaction
strategy,
we're
kind
of
consolidating
the
most
frequently
accessed
things
kind
of
in
the
first
tier,
and
then
they
can,
if
they
exist
longer
than
a
certain
amount
of
time
they
can
be
pushed
down
into
other
ss
tables.
A
A
What
about
road
caching?
This
is
this
is
a
question
that
I've
been
kind
of
struggling
with
for
a
while,
and
there
seems
to
be
some
internal
debate.
I
guess
on
the
mailing
list
as
to
when
to
use
it
or
not.
Jonathan
ellis
had
mentioned,
maybe
potentially
getting
rid
of
row
caching
entirely
for
for
2.0,
and
the
basic
idea
is
that
it's
not
really
necessary.
A
In
most
cases,
row
caches
are
not
really
required,
especially
if
you're
using
you
know,
the
operating
system
will
be
paging
ss
tables
and
or
excuse
me,
it'll
it'll
come
out
of
os
page
cache
and
because
of
the
way
cassandra's
implemented,
it's
basically
opening
native
file
channels
directly
to
the
immutable
ss
table
and
because
that's
in
page
cache
that
that
level
of
direct
read
access
at
a
native.
I
o
level
is
extremely
fast
and
so
there's
there's,
except
for
some
very
very
specific
cases.
It's
almost
always
advisable
not
to
use
row.
A
Caching,
cassandra
will
be
fast
enough
for
this,
but
you
do
want
to
use
a
key
cache.
That's
really
important!
So
it's
enabled
by
default.
You
can
you
can
rely
on
it,
and
so
you
really
don't
have
to
worry
about
row
caches
and
as
an
example.
I
I
did
some
performance
testing
on
this,
where
I
was
slamming
a
local
cluster.
A
I
was
running
on
a
single
node
with
a
lot
of
other
stuff
running
on
that
node.
I
came
up
with
a
test
that
will,
for
each
execution
will
create
a
session
serialize
it
and
store
it
in
cassandra.
It
will
read
that
session,
pull
it
out
of
pull
it
out
of
cassandra
into
local
memory.
It
will
update
some
data
store
it
back
to
cassandra.
It'll
then
delete
the
record
and
then
it'll
query
cassandra
again
to
make
sure
the
record
is
deleted.
A
That's
really
five
operations
at
the
java
level,
which
and
I
executed
that
a
hundred
thousand
times
to
simulate
a
hundred
thousand
concurrent
users
on
a
single
node
and
that
whole
test
ran
in
under
60
seconds.
So
it's
it's
incredibly
fast
in
when
I
turn
on
the
road
cache.
In
that
particular
scenario,
it
only
saved
like
four
or
five
seconds
so
and
that
might
not
have
been
a
reflection
of
cassandra
at
all.
A
A
It's
not
unthinkable
to
support
a
million
plus
users
on
large.
You
know
consumer
based
websites
using
this
technology,
assuming
that
your
tombstones
are
being
cleaned
up
frequently,
so
you
do
want
to
plan
your
session,
your
store
capacity
to
make
sure
it
has
enough
memory
and
enough
cpu
cycles
so
that
when
it
is
compacting,
it's
doing
it
in
an
efficient
manner
and
not
really
affecting
your
runtime
performance
for
your
session
cluster.
So
it's
we've
been
using
it
in
a
testing
environment
and,
aside
from
the
performance
testing,
we've
seen
really
really
good
results
from
this
again.
A
A
And
then
make
sure
your
gc
grace
is
taken
care
of
accordingly.
So
if
you
want
to
see
the
code
for
this,
it's
in
github,
you
can
check
it
out
and
run
an
example
and
and
as
long
as
it
you
know
in
this,
this
particular
code
sample
points
to
a
local
cassandra
node
on
localhost,
but
you
can
just
download
it
run,
jetty
and
and
then
go
to
localhost
and
you'll
actually
see
a
sample
share.
A
There's
no
problems
with
this
stuff,
especially
when
we
tested
under
j
meter
under
a
bunch
of
nodes.
We
had
no
issues
during
our
testing,
but
that's
all
the
time.
I
have
thanks
for
attending
I'll,
be
happy
to
open
the
floor
up
to
questions
either
about
the
cassandra
implementation
or
shiro
in
general.
Or
what
have
you
any
questions?
A
A
A
So
in
our
testing
we
had
no
problems,
everything
worked
well,
we
had
no
issues
and-
and
I
am
we're
actively
evaluating
whether
or
not
we
need
to
keep
our
hazel
class
cluster
up
at
all
for
sessions,
because
this
has
worked
so
well.
So
I
don't,
unless
you
need
the
cash
for
other
reasons,
I
don't
see
a
need
for
keeping
it
just
for
sessions.
You
know
it's
working,
fine,
yes,.
A
Yep
well
for
sessions
yeah
yeah,
so
we
still
use
in
our
architecture.
We
still
have.
You
know
we
access
a
relational
database
for
some
things
and
other
systems
for
others,
and
in
that
case
we
might
use
like
you
know,
we're
using
jpa
or
hibernate.
We'll
keep
us
a
clashing
cluster
available
for
its
needs,
but
we
don't
need
it
for
cassandra's
needs.
A
Does
that
answer
the
question
or
okay,
anything
else
cool?
Well,
I
wish
I
could
have
showed
you
some
of
the
code.
The
session
dao
implementation
is
fairly
trivial,
but
it
does
use
the
cassandra
driver,
which
is
pretty
nice.
It's
got
a
very
jdbc
feel
you
know
with
result,
sets
and
iterating
over
them
and
then
the
sql
is
you've.
Seen
it's
trivial.
You
only
really
need
one
table
and
one
up
cert
query
and
that's
pretty
much
it
well.
The
delete
operation
too
for
shiro's
needs,
but
other
than
that,
it's
very
easy
to
use.
A
But
again
this
is
a
shiro
specific
thing.
You
could
use
it
for
other
kind
of
session
implementations.
I'm
sure
you
could
take
the
same
technique
and
plug
it
into
cassandra's
or
tomcats
caching
infrastructure,
but
I'm
biased.
Why
would
you
do
that
when
you
can
have
a
portable
implementation,
but
so
well,
thanks
for
your
time,
guys
I'll
be
here
to
answer
any
questions.
If
you
have
anything
else
check
out
the
code
on
github,
it's
open
source
under
the
apache
license,
so
you
can
do
whatever
you
want
with
it.