SOA Concurrency Issue

[Anthony Paul]

Hello everyone!

I've been reading a great book on SOA called "Enterprise SOA" and
found that it answered many questions. However, there's one particular
scenario (involving

business-rules) that I'm not sure how to implement under optimistic
concurrency control.

Let's use a Phone-book in our scenario. We can break this down into
Contacts and their respective Phone numbers.

class Contact
{
int ContactID;
string FirstName;
string LastName;
}

class Phone
{
int ContactPhoneID;
int ContactID;
string PhoneNumber;
}

The O/R mapping is trivial in this case, one table per class with each
class property mapping to an identical table column. So far so good.

Since space is limited, we'll set a business-rule where a contact
can't have more than 2 phone numbers; the Enforce method returns a
true if all is well,

false if there's a problem :

class BusinessRulePhone
{
// Enforce maximum 2 phone-numbers allowed per Contact
public bool Enforce(Phone)
{
bool result = true;

if (Phone is a new Phone)
{
int PhoneNumbers = (int) "select count(ContactPhoneID) from Phone
where ContactID = {Phone.ContactID}";
result = (PhoneNumbers < 2); // return false if there are already 2
or more phone-numbers for this contact
}

return result;
}
}

Now let's assume that the contact we'll be focusing on in this
scenario is called "John Doe" and already has a phone-number in the
database. John is a mutual friend of mine and my wife and tells us
that he has a new mobile phone and gives us his number. Later that
afternoon while I'm in my study I decide to add John's new number to
my contact book in my PC. Little do I know that my wife is also in her
studio doing the exact same thing. Since the application is SOA based,
this is where we run into our concurrency issue.

If my wife and I happen to add the phone number at almost the exact
same time, there's a good chance that we'll both read only 1 existing
phone-number in the database and the application will add 2 phone
numbers to the database for a total of 3 numbers for John, effectively
compromising the business-rule.

In order to effectively process the business-rule, it would seem that
we would have to lock (either at app or db level) John's phone numbers
*before* processing the business rules (so that nobody can add/remove
phone-numbers during this transaction), and once all the business-
rules have been run *then* update the database... in other words,
we'll have to resort to pessimistic concurrency control.

I would love to know if there is a way to handle this scenario
optimistically. Also, should the business-layer be involved in placing
locks (either at the app or DB level)? It would seem so since any data
that it references should remain static during the duration of the
transaction.

Any thoughts?

Regards,
Anthony

[John Saunders [MVP]]

"Anthony Paul" <an**********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.com...
....

In order to effectively process the business-rule, it would seem that
we would have to lock (either at app or db level) John's phone numbers
*before* processing the business rules (so that nobody can add/remove
phone-numbers during this transaction), and once all the business-
rules have been run *then* update the database... in other words,
we'll have to resort to pessimistic concurrency control.

I would love to know if there is a way to handle this scenario
optimistically. Also, should the business-layer be involved in placing
locks (either at the app or DB level)? It would seem so since any data
that it references should remain static during the duration of the
transaction.

How about database triggers?
--
John Saunders [MVP]

[Anthony Paul]

Hello John!

I presume you mean "wrap the business-logic inside a trigger". I'm no
expert on the subject but from the little that I have read (and I tend
to agree with), placing business-logic into the database is a no-no.

Regards,

Anthony

On May 15, 3:21 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:

"Anthony Paul" <[e-mail] in message

news:11**********************@n59g2000hsh.googlegr oups.com...
...

In order to effectively process the business-rule, it would seem that
we would have to lock (either at app or db level) John's phone numbers
*before* processing the business rules (so that nobody can add/remove
phone-numbers during this transaction), and once all the business-
rules have been run *then* update the database... in other words,
we'll have to resort to pessimistic concurrency control.

I would love to know if there is a way to handle this scenario
optimistically. Also, should the business-layer be involved in placing
locks (either at the app or DB level)? It would seem so since any data
that it references should remain static during the duration of the
transaction.

How about database triggers?
--
John Saunders [MVP]

[Radek Cerny]

Yes, indeed, timing is everything.

I actually dont see how SOA comes into this; whether a system is
old-fashoined client-server (fat client) or web based should not affect
anything.

There should always be proactive information to the user, eg when
retrieveing a persons details if they aleady have 2 numbers the UI should
report and maybe even enforce the limit.

As for the 'almost-at-the-same-time' scenario, you can place a lock DURING
the transaction, with a check inside the lock, so the first persons insert
would work, and the second would get a message that a rule has been violated
in a very unusual manner - sorry but your changes can not be accepted.

I have used this type of mechanism for many years - now that all my systems
are web-based, nothing changes.

Cheers
"Anthony Paul" <an**********@gmail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...

Hello John!

I presume you mean "wrap the business-logic inside a trigger". I'm no
expert on the subject but from the little that I have read (and I tend
to agree with), placing business-logic into the database is a no-no.

Regards,

Anthony

On May 15, 3:21 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:

>"Anthony Paul" <[e-mail] in message

news:11**********************@n59g2000hsh.googleg roups.com...
...

In order to effectively process the business-rule, it would seem that
we would have to lock (either at app or db level) John's phone numbers
*before* processing the business rules (so that nobody can add/remove
phone-numbers during this transaction), and once all the business-
rules have been run *then* update the database... in other words,
we'll have to resort to pessimistic concurrency control.

I would love to know if there is a way to handle this scenario
optimistically. Also, should the business-layer be involved in placing
locks (either at the app or DB level)? It would seem so since any data
that it references should remain static during the duration of the
transaction.

How about database triggers?
--
John Saunders [MVP]

[John Saunders [MVP]]

"Anthony Paul" <an**********@gmail.comwrote in message
news:11*********************@o5g2000hsb.googlegrou ps.com...

Hello John!

I presume you mean "wrap the business-logic inside a trigger". I'm no
expert on the subject but from the little that I have read (and I tend
to agree with), placing business-logic into the database is a no-no.

The question is whether you want to call it business logic or data integrity
checking. If the latter, then it belongs in the database, where it can
protect the data from such a constraint violation regardless of how it
happens. For instance, this would protect against an attempt by a back-end
data loading process to load data that violates your constraint. Such a
process might not otherwise run your business logic code.
--
John Saunders [MVP]

[KJ]

What is your definition of business logic?

On May 15, 3:55 pm, Anthony Paul <[e-mail]:

Hello John!

I presume you mean "wrap the business-logic inside a trigger". I'm no
expert on the subject but from the little that I have read (and I tend
to agree with), placing business-logic into the database is a no-no.

Regards,

Anthony

On May 15, 3:21 pm, "John Saunders [MVP]" <john.saunders at

trizetto.comwrote:

"Anthony Paul" <[e-mail] in message

news:11**********************@n59g2000hsh.googlegr oups.com...
...

In order to effectively process the business-rule, it would seem that
we would have to lock (either at app or db level) John's phone numbers
*before* processing the business rules (so that nobody can add/remove
phone-numbers during this transaction), and once all the business-
rules have been run *then* update the database... in other words,
we'll have to resort to pessimistic concurrency control.

I would love to know if there is a way to handle this scenario
optimistically. Also, should the business-layer be involved in placing
locks (either at the app or DB level)? It would seem so since any data
that it references should remain static during the duration of the
transaction.

How about database triggers?
--
John Saunders [MVP]

[Anthony Paul]

I think that business logic is a set of rules specific to the business
that maintains the integrity of all of its underlying transactions.
For example, "every employee must have a manager" is a business rule.
"Every employee must have at least two contact phone numbers, one of
which is for emergency purposes" is another. I also think that these
rules should not be tied to any specific implementation; that is, it
should be able to maintain the integrity of the underlying
transactions whether or not they occur against some middleware
component, an oracle database, a flat file, etc... So putting the
business-logic in a database trigger would ensure integrity if the
data came/went from/to the database, but would lead to business-logic
duplication if data were to come/go through a flat-file instead during
a nightly ftp process.

On May 17, 5:09 pm, KJ <[e-mail]:

What is your definition of business logic?

On May 15, 3:55 pm, Anthony Paul <[e-mail]:

Hello John!

I presume you mean "wrap the business-logic inside a trigger". I'm no
expert on the subject but from the little that I have read (and I tend
to agree with), placing business-logic into the database is a no-no.

Regards,

Anthony

On May 15, 3:21 pm, "John Saunders [MVP]" <john.saunders at

trizetto.comwrote:

"Anthony Paul" <[e-mail] in message

>news:11**********************@n59g2000hsh.googleg roups.com...
...

In order to effectively process the business-rule, it would seem that
we would have to lock (either at app or db level) John's phone numbers
*before* processing the business rules (so that nobody can add/remove
phone-numbers during this transaction), and once all the business-
rules have been run *then* update the database... in other words,
we'll have to resort to pessimistic concurrency control.

I would love to know if there is a way to handle this scenario
optimistically. Also, should the business-layer be involved in placing
locks (either at the app or DB level)? It would seem so since any data
that it references should remain static during the duration of the
transaction.

How about database triggers?
--
John Saunders [MVP]- Hide quoted text -

- Show quoted text -

[John Saunders [MVP]]

"Anthony Paul" <an**********@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...

>I think that business logic is a set of rules specific to the business
that maintains the integrity of all of its underlying transactions.
For example, "every employee must have a manager" is a business rule.
"Every employee must have at least two contact phone numbers, one of
which is for emergency purposes" is another. I also think that these
rules should not be tied to any specific implementation; that is, it
should be able to maintain the integrity of the underlying
transactions whether or not they occur against some middleware
component, an oracle database, a flat file, etc... So putting the
business-logic in a database trigger would ensure integrity if the
data came/went from/to the database, but would lead to business-logic
duplication if data were to come/go through a flat-file instead during
a nightly ftp process.

But if the flat file is never imported into the database, why do you care
whether what's in it passes the business rules?

Personally, my feeling is that, if the business rule ensures data integrity,
then put it into the database. The database software knows best how to do
this efficiently, and it's a single point through which all business
transactions have to pass, no matter how they enter the system.
--
John Saunders [MVP]

[Anthony Paul]

Please correct me if I'm wrong but I think I can distill the replies
I've had so far into the following : 1) business rules are seperate
from data-integrity logic and 2) it is okay to duplicate data-
integrity logic. Is this the recommended approach?

Regards,

Anthony

On May 18, 7:43 pm, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:

"Anthony Paul" <[e-mail] in message

news:11**********************@k79g2000hse.googlegr oups.com...

I think that business logic is a set of rules specific to the business
that maintains the integrity of all of its underlying transactions.
For example, "every employee must have a manager" is a business rule.
"Every employee must have at least two contact phone numbers, one of
which is for emergency purposes" is another. I also think that these
rules should not be tied to any specific implementation; that is, it
should be able to maintain the integrity of the underlying
transactions whether or not they occur against some middleware
component, an oracle database, a flat file, etc... So putting the
business-logic in a database trigger would ensure integrity if the
data came/went from/to the database, but would lead to business-logic
duplication if data were to come/go through a flat-file instead during
a nightly ftp process.

But if the flat file is never imported into the database, why do you care
whether what's in it passes the business rules?

Personally, my feeling is that, if the business rule ensures data integrity,
then put it into the database. The database software knows best how to do
this efficiently, and it's a single point through which all business
transactions have to pass, no matter how they enter the system.
--
John Saunders [MVP]

[=?Utf-8?B?VEg=?=]

Why don't you modify the rule to include "unique" phone numbers? In this
case, it doesn't matter who enters in the phone number when - as long as it's
a unique number.