dirty read from database

[ddumas]

I am new to Aware IM.

From the getting started guide, I see this as a business rule:

IF
Member IS NEW
THEN
Member.MemberNumber = MAX Member.MemberNumber+1

In a potentially high volume environment, and where the default of database isolation level is set to READ COMMITTED (the best option), using the above logic could potentially assign the same sequential number to multiple object instances, due to dirty reads.

Does anyone know Aware IM protects against this dirty read from happening? Or, alternatively, is there a better design for this type of rule, such that underlying database objects, such as db sequences, are used. Sequences are only assigned in a locked state, and thus will never assign a duplicate value.

[pbrad]

Hi,
One bullet proof method is to use a rule like:

IF
Member IS NEW
THEN
Member.MemberNumber = SystemSettings.MemberNumber
SystemSettings.MemberNumber=SystemSettings.MemberNumber+1

With this method you cannot end up with duplicate member numbers. Use can also use auto increment on the attribute.
Cheers,
Pete

[ddumas]

Hi,
One bullet proof method is to use a rule like:

IF
Member IS NEW
THEN
Member.MemberNumber = SystemSettings.MemberNumber
SystemSettings.MemberNumber=SystemSettings.MemberNumber+1

With this method you cannot end up with duplicate member numbers. Use can also use auto increment on the attribute.
Cheers,
Pete

Thanks Pete. So, are SystemSettings attributes "read" locked during the execution of a business rule? Otherwise you could still get a dirty read in the execution of the first statement, correct?

Dave

[pbrad]

One of your first challenges is to get around your existing paradigm for database management. Let the rules do the work and the database will take care of itself.

In this case, as soon as the rule is run upon saving your member object, the next member number is incremented in system settings which is always available in context to all rules and processes. There is no possibility under any conditions of the same number being made available to another object.

Pete

[ddumas]

One of your first challenges is to get around your existing paradigm for database management. Let the rules do the work and the database will take care of itself.

In this case, as soon as the rule is run upon saving your member object, the next member number is incremented in system settings which is always available in context to all rules and processes. There is no possibility under any conditions of the same number being made available to another object.

Pete

I like that. And yes, still wrapping my head around db stuff that I had to deal with in more traditional, non-object tools

Dave

[aware_support]

Please read a section in the User Guide about transaction handling in Aware IM - will be useful for any database expert.

A better approach for assigning incremental ID's is to use Number attributes with "Auto-Incremented" checkbox ticked. Auto-incremented numbers have been designed specifically to guarantee uniqueness under any circumstances and avoid "dirty-reads" problem.

[ddumas]

Please read a section in the User Guide about transaction handling in Aware IM - will be useful for any database expert.

A better approach for assigning incremental ID's is to use Number attributes with "Auto-Incremented" checkbox ticked. Auto-incremented numbers have been designed specifically to guarantee uniqueness under any circumstances and avoid "dirty-reads" problem.

Excellent - thanks!

Dave