> It's me who talk about select for update :) > > To resume that we say, the theorical principle of the independent > business tier is very nice but difficult (to not say not possible) to > implement. Checking rules in the business tier is not reliable in case > of multithreading and it's more safe (and easy to test) to duplicate > constraints in the db. > Do you agree with that?
Well, it's not that checking the rules at the business tier is not reliable, it is much more difficult to accomplish and to rely on that without using the DB facilities sounds to me like checking bussines rules at the client side with JavaScript (I know it is not the same). I see the data tier and bussines logic tier as one thing. I agree that if your design had to be prepared for using different kind of persistence mechanisms, like flat files, an LDAP repository... you would then choose not to use DB constraints and the bussiness logic would have to be an independent entity, but that does not happen very often and doing so when you know you will allways be using a database does not make much sense to me. Independent tiers sound very nice theoretically but then comes reality and your common sense, so you can adapt them to your situation. > The problem is that most people seems to believe that an EJB server > manage all multithreading problems and i never read an article or a book > where it's said you must set constaints otherwise you could have some > problems. Well, that it's not written does not mean it is not there :). They also say you should always set your FK in ejbPostCreate, never in ejbCreate, but what happens when your FK cannot be set to null? Do you have to modify your DB constraints just because of the EJB spec? I think we are driving off-topic roads :) > Jean-Philippe -- This message was sent using Sake Mail, a web-based email tool from Endymion Corporation. http://www.endymion.com/products/sakeIt's me who talk about select for update :)
To resume ?that we say, the theorical principle of the independent business tier is very nice but difficult (to not say not possible) to implement. ?Checking rules in the business tier is not reliable in case of multithreading and it's more safe (and easy to test) to duplicate constraints in the db.
Do you agree with that?
The problem is that most people seems to believe that an EJB server manage all multithreading problems and i never read an article or a book where it's said you must set constaints otherwise? you could have some problems.
Jean-Philippe
[EMAIL PROTECTED] wrote:
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/sake
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?
