►
Description
This is the details on why do we need a row-level locking for a Vulnerability Occurrence (to be renamed to Finding) when we decide to create a new Vulnerability from it and attach this Finding to it.
A
Okay,
great,
this
is
a
brief
explanation
form.
Why
do
we
need
level
locking
for
the
creation
of
vulnerabilities
from
occurrences?
First
of
all,
let's
check
our
models.
We
have
first
model
called
vulnerabilities
occurrence
in
the
new
terminology.
It
is
called
finding
and
this
will
be
changed
after
this
feature
reaches
is
post
analysis
state
now,
it's
called
occurrence
occurrence
belongs
to
vulnerability.
Vulnerability
is
like
an
epic
object.
It
is
collection
of
many
occurrences.
Occurrences
are
detected
by
security
scanners
and
are
scattered
across
the
source
code
of
the
project.
A
Vulnerability
is
like
user
interactable
object,
which
has
references
to
all
of
its
occurrences,
and
it
has
a
unique
identifier
in
the
advisories
database,
databases
that,
by
which
you
may
refer
out
so
a
vulnerability
of
this
way,
has
many
findings
and
the
currents.
Do
one
stop
on
our
duty
here.
We
don't
have
the
words
to
Association,
but
if
we
will
examine
the
database,
we
will
find
this
vulnerability.
Id
column
and
many
occurrences
can
go
on
to
the
same
vulnerability
get
back
to
the
service
class.
A
Why
do
we
need
to
lock
the
occurrence
record
how
the
creation
works?
The
creation
service
accepts
find
an
ID,
so
the
idea
that
the
user
may
promote
any
occurrence
into
a
vulnerability.
It
examines
one
source
file,
a
source
code
file.
It
finds
a
occurrence
of
a
vulnerability
and
it
can
be
promoted
to
a
vulnerability
object
later
on
and
other
occurrences
of
the
same
vulnerability
can
be
associated
with
this
vulnerability
object.
A
A
But
here
is
the
problem.
Two
transactions,
two
or
more
transactions
may
try
to
use
the
same
finding
ID
to
promote
into
a
vulnerability,
and
we
must
ensure
that
if
we
have
found
a
finding-
and
we
need
to
understand-
was
it
operat
attached
to
anyone
or
ability
or
not
if
it
was,
we
cannot
switch
the
relation.
This
finding
was
already
attached
to
another
vulnerability
before
by
another
user,
and
we
just
report
an
error
and
exit,
but
because
of
the
lack
of
thread
synchronization,
there
could
be
risk
condition
when
both
of
these
two
competing
transactions.
A
A
So
they
both
update
the
vulnerability,
ID
column
with
the
newly
created
ID
or
vulnerability.
What
this
record
and
the
last
transaction
wins.
We
have
a
race
condition,
so
we
need
to
ensure
that
this
state,
this
unattached
state,
which
is
represented
by
a
bomber
ability,
ID,
is
neo
persists
until
the
end
of
transaction
and
no
other
transaction
can
read
it
or
update
it
until
this
transaction
end
and
we,
this
is
important.
A
We
need
lock-in
not
only
for
updating
but
also
for
reading,
because
if
another
transaction
will
be
able
to
read
this
record,
it
will
launch
this
process
of
creating
new
vulnerability
and
attaching
itself
to
it
unique
constraints,
usually
a
better
replacement
for
row
level
Locker,
but
they
will
not
work
on
this
case,
because
when
we
look
at
the
vulnerability
occurrences
table
and
the
vulnerability
ID,
we
remember
that
it
is,
has
many
relationship,
so
many
different
occurrence
records
will
may
have
the
same
vulnerability
empty
because
they
are
children
of
the
same
vulnerability
object.
So
we
not.
A
A
So
in
essence
a
vulnerability
ID
might
belong
to
and
excuse
me,
a
vulnerability
occurrence
may
belong
to
any
vulnerability,
but
our
intent
here,
if
is,
if
we
have
chosen
this
occurrence,
to
belong
to
a
newly
created
vulnerability.
No
other
transaction
should
prevent
us
from
finishing
this
operation
sequence.
That's
it!
Thank
you
for
your
attention.