I agree with that.
The wrong design is using db constraint to manage rules which should be located in the business tier. That's to say not coding a rule because you know that a constraint has been set within the db.

But coding a business tier which is able to manage all rules without using constraint seems to be difficult and i don't know if following this theorical principle is possible. Especially in a multithreading environment.

I guess that if i have problem to check the unicity of a field, i will have some problems in coding more complex rules.

What is your mind about that? How do you check that something is unique?

Jean-Philippe
?

[EMAIL PROTECTED] wrote:
Hi,
Whatever you do at the other tiers, I wouldn't call defining a PK a wrong
design. That is ENFORCING a rule, it does not mean you have to let the DB handle
the detection of a duplicated value, it just means that the DB won't allow you
to introduce a duplicate value, in case you have bug or something similar, not
unlikely to happen at the beginning in multithreaded environments. Another
advantage is that if someday you introduce data in your DB through another tier,
like a batch job with a bunch of SQL commands or a native application, the
contraint is still enforced. IMHO, unless you put a lot of access restrictions
on your DB, if you check all of that only at the upper tiers you cannot
guarantee the data is consistent at the DB.
Just my 2ec,
D.

  
Yes, but my name is no defined as a PK and i don't want to use unicity 
constraint (in fact i don't know if the default jboss database manages 
it, the @pk-constaint tag has no effect.

Moreover, if your name is defined as a PK, you don't need any more to 
check the unicity and you have a wrong design with some rules managed by 
the db tier.
At least, i've been said that the ejb server can delay the call to 
ejbstore. In this case you get your  exception after the call (at the 
end of the transaction i guess) of the create function which can be 
difficult to manage.
    


--
This message was sent using Sake Mail, a web-based email tool from
Endymion Corporation.  http://www.endymion.com/products/sake

  



Yes, but my name is no defined as a PK and i don't want to use unicity constraint (in fact i don't know if the default jboss database manages it, the @pk-constaint tag has no effect.

Moreover, if your name is defined as a PK, you don't need any more to check the unicity and you have a wrong design with some rules managed by the db tier.
At least, i've been said that the ejb server can delay the call to ejbstore. In this case you get your ?exception after the call (at the end of the transaction i guess) of the create function which can be difficult to manage.

[EMAIL PROTECTED] wrote:
If the name is defined as a PK I think you shouldn't have any problem...

On Tue, 2003-07-29 at 03:46, Jean-philippe VIGNIEL wrote:
  
What appens if two persons create the same object at the same time. With 
the default transaction mode, i think  (but i can be wrong) that the 
object can be created twice.

By example;

User1: select * from object where name="bob"->nothing  so it's ok
User2: select * from object where name="bob"->nothing so it's ok
User1: create "bob"
User2: create "bob"
User1: close transaction
User2: Close transaction

And there are two bob objects within the database.


Before EJB tomanage this case we did a select for update. Perhaps it's 
possible to set the transaction mode to serialized for the create method???

Thanks for your advice about with subject?


    

  


Reply via email to