RE: Official implementation request.
Hi Nathan, If you have a compound primary key of say 7 columns and 6 of them are (or can be) blank or null then only the seventh column can be used as a real primary key. So from an OJB point of view you could just solve the issue by declaring on the seventh column as primary key in the repository. I don't that it is a good idea to implement the feature you request because it fosters violations of the relational calculus. just my 2c, Thomas -Original Message- From: Nathan Smith [mailto:[EMAIL PROTECTED] Sent: Friday, August 20, 2004 2:08 AM To: [EMAIL PROTECTED] Subject: Official implementation request. Hi all, LabPro 2000 Ltd is a specialist provider of information management systems including LIMS (Laboratory Information Management Systems). We here at www.labpro2000.com currently use OJB as part of our eQual application development (http://demo.labpro2000.com). This is a redevelopment of the current application Labpro. To put it simply LabPro, is a QA solution for any testing. We use an RDBMS developed by a little known company called Progress (http://www.progress.com/progress/index.ssp). The RDBMS is a very good database but not many people have heard of it, so it is not really mainstream. The problem is this RDBMS allows records to be inserted with blank or null values for fields of the primary key. For example we have a table that uses 7 fields/columns as part of the PK. A record could be inserted with 6 of those fields blank or null. The use of the table is a special case as it defines range limits that testing results must fall within for a particular product to be assigined a quality code. One of the records in this table depending on what fields are blank can used for multiple products. We also have another table which is used in similar fashion The proposal: Can the repository.xml contain some property or database specific metadata element which can be used to determine whether NULL's or blanks can be used as ligitimate values for PK fields. Or maybe another way would be to enable some sort of callback that can be implemented through the Platform interface. Look forward to hearing your ideas. Nathan Smith Software Developer LabPro 2000 Limited Phone: +64 4 586 6840 Facsimile: +64 4 586 6841 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.labpro2000.com/ www.labpro2000.com Level 6, Riverside Tower on Daly, 15 Daly Street Lower Hutt, New Zealand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Oracle and case-insensitive search
Hi, In Oracle a search on a string (Criteria.addLike) seems to be Case Sensitive. How do you guys solve this problem. In MsSql and MySql a Criteria.addLike is not case sensitive ! Thanks, Frank Renaers
Re: Oracle and case-insensitive search
Hi, you can just do something like this... Criteria c = new Criteria(); c.addLike( upper(yourField), yourString.toUpperCase() ); cheers Danilo Hi, In Oracle a search on a string (Criteria.addLike) seems to be Case Sensitive. How do you guys solve this problem. In MsSql and MySql a Criteria.addLike is not case sensitive ! Thanks, Frank Renaers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Official implementation request.
Hi, When we need this, I never use database NULL value for PK, instead I use a String initiated with 'NULL' then the Querys can change from: SELECT * FROM table1 WHERE field1 IS NULL AND field2 = '0001' to: SELECT * FROM table1WHERE field1 = 'NULL' AND field2 = '0001' This idea work on any Database, only you must to do is define what is your constant to NULL value. Hope this help Clóvis Nathan Smith wrote: Hi all, LabPro 2000 Ltd is a specialist provider of information management systems including LIMS (Laboratory Information Management Systems). We here at www.labpro2000.com currently use OJB as part of our eQual application development (http://demo.labpro2000.com). This is a redevelopment of the current application Labpro. To put it simply LabPro, is a QA solution for any testing. We use an RDBMS developed by a little known company called Progress (http://www.progress.com/progress/index.ssp). The RDBMS is a very good database but not many people have heard of it, so it is not really mainstream. The problem is this RDBMS allows records to be inserted with blank or null values for fields of the primary key. For example we have a table that uses 7 fields/columns as part of the PK. A record could be inserted with 6 of those fields blank or null. The use of the table is a special case as it defines range limits that testing results must fall within for a particular product to be assigined a quality code. One of the records in this table depending on what fields are blank can used for multiple products. We also have another table which is used in similar fashion The proposal: Can the repository.xml contain some property or database specific metadata element which can be used to determine whether NULL's or blanks can be used as ligitimate values for PK fields. Or maybe another way would be to enable some sort of callback that can be implemented through the Platform interface. Look forward to hearing your ideas. Nathan Smith Software Developer LabPro 2000 Limited Phone: +64 4 586 6840 Facsimile: +64 4 586 6841 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.labpro2000.com/ www.labpro2000.com Level 6, Riverside Tower on Daly, 15 Daly Street Lower Hutt, New Zealand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: pbapi + select from multiple tables
Hi, in your BAR class you don't declare a collection for FOO, and a collection for BAR childs? Joose Vettenranta wrote: I have like FOO and BAR classes and it's 1:n connection.. There can be lot's of FOO pointing to same BAR id and BAR has parent id which points to BAR itself now I would like to fetch something from that tree.. My first idea was this: in SQL: select * from FOO,BAR where BAR.parent=id and BAR.id=FOO.bar_id; but now that I was writing this, can I some how fetch the subtree from BAR? basicely BAR is a tree where there is 1 root element and then childs and their childs .. etc.. I tried to look at http://db.apache.org/ojb/docu/guides/query.html but couldn't find anything to help me. of course one option could be to make a recursive function to go through whole tree, maybe it's what I have to do... Thanks, Joose -- Always remember that you are unique, just like everyone else! * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB+JNDI Datasource clarification
hi, I have read some postings about OJB's datasource handling and I'm confused now. It's said, that you have to a.) put username/password both in the datasource.xml and repository_database.xml or b.) let username/password blank and give it to the broker (with pbkey) at runtime. why is that? if I tell ojb in repository_database.xml to use a specifc JNDI datasource, ojb could obtain a connection from this datasource without a password/username (because they are already configured wihtin the datasource), so why does ojb need them again? thanks very much for your answers, andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OJB+JNDI Datasource clarification
hi, I have read some postings about OJB's datasource handling and I'm confused now. It's said, that you have to a.) put username/password both in the datasource.xml and repository_database.xml or b.) let username/password blank and give it to the broker (with pbkey) at runtime. why is that? if I tell ojb in repository_database.xml to use a specifc JNDI datasource, ojb could obtain a connection from this datasource without a password/username (because they are already configured wihtin the datasource), so why does ojb need them again? thanks very much for your answers, andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Official implementation request.
I'd tend to force an artificial primary key (as an extra field); but I suppose the customization options offered by OJB would allow you to write your own call-back to enable the kind of functionality your talking about. Clóvis Wichoski wrote: Hi, When we need this, I never use database NULL value for PK, instead I use a String initiated with 'NULL' then the Querys can change from: SELECT * FROM table1 WHERE field1 IS NULL AND field2 = '0001' to: SELECT * FROM table1WHERE field1 = 'NULL' AND field2 = '0001' This idea work on any Database, only you must to do is define what is your constant to NULL value. Hope this help Clóvis Nathan Smith wrote: Hi all, LabPro 2000 Ltd is a specialist provider of information management systems including LIMS (Laboratory Information Management Systems). We here at www.labpro2000.com currently use OJB as part of our eQual application development (http://demo.labpro2000.com). This is a redevelopment of the current application Labpro. To put it simply LabPro, is a QA solution for any testing. We use an RDBMS developed by a little known company called Progress (http://www.progress.com/progress/index.ssp). The RDBMS is a very good database but not many people have heard of it, so it is not really mainstream. The problem is this RDBMS allows records to be inserted with blank or null values for fields of the primary key. For example we have a table that uses 7 fields/columns as part of the PK. A record could be inserted with 6 of those fields blank or null. The use of the table is a special case as it defines range limits that testing results must fall within for a particular product to be assigined a quality code. One of the records in this table depending on what fields are blank can used for multiple products. We also have another table which is used in similar fashion The proposal: Can the repository.xml contain some property or database specific metadata element which can be used to determine whether NULL's or blanks can be used as ligitimate values for PK fields. Or maybe another way would be to enable some sort of callback that can be implemented through the Platform interface. Look forward to hearing your ideas. Nathan Smith Software Developer LabPro 2000 Limited Phone: +64 4 586 6840 Facsimile: +64 4 586 6841 mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.labpro2000.com/ www.labpro2000.com Level 6, Riverside Tower on Daly, 15 Daly Street Lower Hutt, New Zealand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Robert r. Sanders Chief Technologist iPOV www.ipov.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OJB+JNDI Datasource clarification
thanks for your quick response, armin! I see, the pwd/user settings in repository_user.xml are optional! ok, that's good, so I have only one problem left. maybe you can give me a hand with this: I have just one ear file with my ejb's, war's, jar's and ojb.sar inside, and I have my datasource.xml which is outside the ear (in the deploy dir). I want to let our customer specify the database connection via the datasource(which driver to use, username, password) without the need to modify our ear file (and the repository files within..) I know how to set the platform at runtime, but how can I figure out which plattform is used? i could open a connection via jndi, get the driver name via metadata and build a mapping from driver name to ojb plattform name. would that be a good solution? andreas Armin Waibel wrote: Hi Andreas, please have a look at javadoc of DataSource http://java.sun.com/j2se/1.4.2/docs/api/javax/sql/DataSource.html#getConnection(java.lang.String,%20java.lang.String) It is possible to setup DataSource with the ability to specify user/password at runtime. if I tell ojb in repository_database.xml to use a specifc JNDI datasource, ojb could obtain a connection from this datasource without a password/username (because they are already configured wihtin the datasource), so why does ojb need them again? If your DataSource does not expect user/password, you don't need to set this in repository_database. But some user don't want to specify user/password in an configuration file (in OJB or in the app providing the Datasource), thus you have to pass it at runtime. regards, Armin abo wrote: hi, I have read some postings about OJB's datasource handling and I'm confused now. It's said, that you have to a.) put username/password both in the datasource.xml and repository_database.xml or b.) let username/password blank and give it to the broker (with pbkey) at runtime. why is that? if I tell ojb in repository_database.xml to use a specifc JNDI datasource, ojb could obtain a connection from this datasource without a password/username (because they are already configured wihtin the datasource), so why does ojb need them again? thanks very much for your answers, andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Massive concurrency problems under high server load
Hi,
We have developed a servlet application using a slightly modified
version of OJB 1.0RC5 using the ODMG API. The application has been
tested with Unit Tests, comprehensive manual funcional tests, and
(mainly single-threaded) performance tests and everything seemed to
work well.
As last step before going online we performed several load tests on
the application and found ourselves faced with a pile of problems.
These include inacceptable performance (simple transactions taking
several minutes), database deadlocks, complete irresponsiveness of the
application server and all kinds of Java exceptions, most of which
originating deeply within the OJB code.
An obvious approach to try to resolve some of these problems would be
to move to OJB version 1.0, but in an earlier attempt we found that
some of our modifications were incompatible with 1.0. Given the time
pressure we decided to stay with RC5 as it seemed to work for us.
Now the time pressure is quite a bit higher and we have to judge
whether upgrading to OJB 1.0 would help enough to resolve the
concurrency problems to justify the time necessary for the upgrade.
So my main questions are:
- Have substantial things changed between RC5 and 1.0 that might have
improved OJB's behavior under high concurrent load.
- Does anyone have experience with OJB in a servlet environment under
high load? Any hints how to get it to work and perform?
One finding that discourages us from upgrading to 1.0 is a concurrency
bug we discovered in RC5 which does not seem to have been fixed in
1.0:
In class org.apache.ojb.broker.core.QueryReferenceBroker:
private void performRetrievalTasks()
{
while (m_retrievalTasks.size() 0)
{
HashMap tmp = m_retrievalTasks; // *
m_retrievalTasks = new HashMap(); // *
// during execution of these tasks new tasks may be added
for (Iterator it = tmp.entrySet().iterator(); it.hasNext(); )
...
the two lines marked with // * must be put in a block that
synchronizes (e.g.) on m_retrievalTasks. If not, a thread switch may
occur after the first line and two instances of tmp may point to the
same hash table. Seems unlikely, but under high load it does occur
often enough (a java.util.ConcurrentModification exception is the
consequence):
synchronized (m_retrievalTasks) {
tmp = m_retrievalTasks;
m_retrievalTasks = new HashMap();
}
solves the problem.
Any hints and help are greatly appreciated.
Gerhard Grosse
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
out of the box SQL - .java tool?
Almost a year ago, we had started an in-house tool development like such, we figured since OJB has matured so much that there would be a mature tool to do such, preferably from ant. http://db.apache.org/ojb/docu/howtos/howto-build-mappings.html says that the ReverseDB tool is not up to date :( Any links, ideas, etc. Sincerely, Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Partner Sr. Manager Pyerotechnics Development, Inc. - - +1 (443) 451-2697 500 West University Parkway #1S - - +1 (410) 808-6646 (c) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Massive concurrency problems under high server load
Hi Gerhard,
this sounds alarming :-(
Gerhard Grosse wrote:
So my main questions are:
- Have substantial things changed between RC5 and 1.0 that might have
improved OJB's behavior under high concurrent load.
we made serveral improvements between rc5 and 1.0. The performance
improvement of the odmg-api should be about 10-15%. The handling of
nested objects was improved significantly (~ 250% better performance).
But I think this will not solve the described problems of transactions
take minutes to complete.
OJB was shipped with a simple multi-threaded performance test. This test
pass on all releases (but only on my single cpu PC).
- Does anyone have experience with OJB in a servlet environment under
high load? Any hints how to get it to work and perform?
One finding that discourages us from upgrading to 1.0 is a concurrency
bug we discovered in RC5 which does not seem to have been fixed in
1.0:
In class org.apache.ojb.broker.core.QueryReferenceBroker:
private void performRetrievalTasks()
{
while (m_retrievalTasks.size() 0)
{
HashMap tmp = m_retrievalTasks; // *
m_retrievalTasks = new HashMap(); // *
// during execution of these tasks new tasks may be added
for (Iterator it = tmp.entrySet().iterator(); it.hasNext(); )
...
the two lines marked with // * must be put in a block that
synchronizes (e.g.) on m_retrievalTasks. If not, a thread switch may
occur after the first line and two instances of tmp may point to the
same hash table. Seems unlikely, but under high load it does occur
often enough (a java.util.ConcurrentModification exception is the
consequence):
synchronized (m_retrievalTasks) {
tmp = m_retrievalTasks;
m_retrievalTasks = new HashMap();
}
solves the problem.
hmm, the PB-api is not threadsafe by design, so if this happens the
problem will be occured by the odmg-api (missing synchronized block ...)
or does it happen when lazy loading of objects was used?
regards,
Armin
Any hints and help are greatly appreciated.
Gerhard Grosse
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Massive concurrency problems under high server load
I run some massive multithreaded tests against the 1.0_RELEASE branch in
CVS (against hsql in-memory mode, single CPU) without failures (with
tweaked OJB settings). In this test each thread work on separate
objects, maybe the problems occur only when different threads work on
the same objects.
So could you post some of the exceptions you got when run your tests and
some info about the test (concurrent threads, OJB configuration, ...)?
regards,
Armin
[ojb]
[ojb] OJB PERFORMANCE TEST SUMMARY
[ojb] 100 concurrent threads, handle 500 objects per thread
[ojb] - performance mode
[ojb]
[ojb] API Period Total Insert Fetch Update Delete
[ojb][sec] [sec] [msec] [msec] [msec] [msec]
[ojb]
[ojb] ODMG 63.833 59.424 19117 17445 138509011
[ojb]
[ojb] PerfTest takes 194 [sec]
[ojb]
[ojb] OJB PERFORMANCE TEST SUMMARY
[ojb] 40 concurrent threads, handle 2000 objects per thread
[ojb] - performance mode
[ojb]
[ojb] API Period Total Insert Fetch Update Delete
[ojb][sec] [sec] [msec] [msec] [msec] [msec]
[ojb]
[ojb] ODMG 90.255 80.836 40198 10361 20026 10250
[ojb]
[ojb] PerfTest takes 274 [sec]
Armin Waibel wrote:
Hi Gerhard,
this sounds alarming :-(
Gerhard Grosse wrote:
So my main questions are:
- Have substantial things changed between RC5 and 1.0 that might have
improved OJB's behavior under high concurrent load.
we made serveral improvements between rc5 and 1.0. The performance
improvement of the odmg-api should be about 10-15%. The handling of
nested objects was improved significantly (~ 250% better performance).
But I think this will not solve the described problems of transactions
take minutes to complete.
OJB was shipped with a simple multi-threaded performance test. This test
pass on all releases (but only on my single cpu PC).
- Does anyone have experience with OJB in a servlet environment under
high load? Any hints how to get it to work and perform?
One finding that discourages us from upgrading to 1.0 is a concurrency
bug we discovered in RC5 which does not seem to have been fixed in
1.0:
In class org.apache.ojb.broker.core.QueryReferenceBroker:
private void performRetrievalTasks()
{
while (m_retrievalTasks.size() 0)
{
HashMap tmp = m_retrievalTasks; // *
m_retrievalTasks = new HashMap(); // *
// during execution of these tasks new tasks may be added
for (Iterator it = tmp.entrySet().iterator(); it.hasNext(); )
...
the two lines marked with // * must be put in a block that
synchronizes (e.g.) on m_retrievalTasks. If not, a thread switch may
occur after the first line and two instances of tmp may point to the
same hash table. Seems unlikely, but under high load it does occur
often enough (a java.util.ConcurrentModification exception is the
consequence):
synchronized (m_retrievalTasks) {
tmp = m_retrievalTasks;
m_retrievalTasks = new HashMap();
}
solves the problem.
hmm, the PB-api is not threadsafe by design, so if this happens the
problem will be occured by the odmg-api (missing synchronized block ...)
or does it happen when lazy loading of objects was used?
regards,
Armin
Any hints and help are greatly appreciated.
Gerhard Grosse
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
