►
Description
Here are the details of 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
what
I
do
need
without
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
its
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
Do
one
stop
on
our
ability?
Here
we
don't
have
those
two
Association,
but
if
we
will
examine
the
database,
we
will
find
this
vulnerability.
Id
column
and
many
occurrences
can
belong
to
the
same
vulnerability,
get
back
to
the
service
class.
Why
do
we
need
to
lock
the
occurrence
record
how
the
British
works?
The
creation
service
accepts
finding
AG,
so
the
idea
that
the
user
may
promote
any
occurrence
into
a
vulnerability.
A
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.
So
we
create
a
new
object
here.
We
created
just
a
memory
and
then
we
try
to
resist
it
and
to
associate
this
file
with
vulnerability
occurrence
and
find
in
terms
I
can
be
used
here
interchangeably.
A
But
here
is
the
problem.
Two
transactions,
two
or
more
transactions
may
try
to
use
the
same
finding
idea
to
promote
into
a
vulnerability,
and
we
must
ensure
that
if
we
have
found
a
finding-
and
we
need
to
understand-
was
it
already
attached
to
any
bomber
ability
or
not
if
it
was,
we
cannot
switch
the
relation.
A
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
in
this
condition
when
both
of
these
two
competing
transactions,
they
fetch
the
same
occurrence
by
the
same,
find
an
ID.
The
read
the
same
state
that
vulnerability
ID
is
no.
It
is
not
attached
to
any
vulnerability,
then
both
of
them
create
this
vulnerability
record
here
and
both
of
them
attach
this
found
in
to
this
vulnerability.
A
So
they
both
update
the
vulnerability
ID
column
with
the
newly
created
ID
of
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
vulnerability
ID,
is
nil,
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
Unique
constraints
usually
a
better
replacement
for
row
level
Locker,
but
they
will
not
welcome
this
case,
because
when
we
look
at
the
vulnerability
occurrences
table
and
the
vulnerability
IG,
we
remember
that
it
is,
has
many
relationship,
so
many
different
occurrence
records
will
make
the
same
vulnerability
empty
because
they
are
children
of
the
same
vulnerability
object.
So
we
not.
We
cannot
create
a
vulnerability,
ID
unique
index
here.
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.