Hi, Well, as someone suggested, if you have to do something like that in a multithreading environment, you have to use something like select-for-update so the DB is blocked between your select-check and your insert. I was developing before using PLSQL (directly generating XML) so I was able to use select-for-update and sequences to take care of that. Now that I'm playing with EJB... well, I started using sequences but I wanted to be DB independente, so at the moment I am using xdoclet autogenerated pk and they seem to work fine. I have all the PK and FK constraints in my DB and so far none was activated by a badly generated PK. However, I'm just accessing the DB through my EJB layer, so you could say the PK constraints are a bug checking backup. On the other hand, I let the DB handle some of the FK and Unique constraints. The FK problems should not normally arise, as the program is developed you don't have the option of choosing twice a relationship, or removing it twice, but it could happen when race conditions occur. In this case I catch the appropriate Exception and notify the user with a more user-friendly message. I consider the DB and its contraints part of the business-model so even though there are some risks at doing so, I let them take its part of checks. Duplicating what the constraints do is sometimes quite difficult as you are checking data consistency at a layer well above where the data is, so the blocking and checking that is easy to do at the DB is not easy to do for you. Where to draw the line between checking at the DB and checking at the business-logic? Well, it is a difficult line to draw and I believe there's no definite answer, as you have to take into account other things like DB-independence (if you need it or not), will the DB just be accessed through one business-logic tier?... I usually start making it impossible to put inconsistent data in the DB, that usually means db constraints, and then add the checking and handling above that allow me to report the possible problems nicely and ASAP to the user, wherever it is better done without over-bloating the code. But as I said, other environments could be better handled with other approaches. Just my 2ec, D.
> 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 -- This message was sent using Sake Mail, a web-based email tool from Endymion Corporation. http://www.endymion.com/products/sakeI 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?
