BUG(?): 2 classes, same table name, different database
If this is a bug, hope some developer knows how to fix this. for now, I made this "glue" solution, I just add database in front of every table name. like db1_admin db2_admin and then ojb doesn't mix up those data. more information: in db1: create table admin ( uid varchar(20) not null, password varchar(20) not null, primary key(uid)); in db2: create table admin ( id serial, login varchar(30) not null, password varchar(30) not null, email varchar(100), primary key(id)); so when trying to fetch admin from db2 it tries to take uid also and SqlException happenens (see below) Thanks, Joose 15.11.2004 kello 13:57, Joose Vettenranta kirjoitti: So, is this a bug in OJB? So one software, 2 database 2 classes 2 different kind of table, but they are both named same => table <-> class mapping is not working - Joose 12.11.2004 kello 09:43, Joose Vettenranta kirjoitti: I forgot to say, that I have different dbuser and different connection for both of dabases. And both connection is described with jdbc-connection-descriptor -element and using : Thanks, Joose 12.11.2004 kello 09:33, Joose Vettenranta kirjoitti: Hi, I have 2 databases, let's call them db1 and db2 in db1 I have table called admin in db2 I have also table called admin but they are not like each other, they have different kind of table structure. for db1 I have a class to access table admin, let's call it net.vettenranta.db1.AdminImpl; for db2 I have a class to access table admin, let's call it net.vettanranta.db2.Admin; Now, here is the problem: when I try to get data from db2 it tries also get db1's fields (most likely same happens to db1 class, but have not tried yet) which causes error: Caused by: java.sql.SQLException: ERROR: No such attribute a0.uid So, is it possible to tell ojb that "heyy, it's this db2.Admin reference you have to use from repository, not db1.AdminImpl"? Using ojb1.0.1 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]
ObjectCacheEmptyImpl that handles recursive references
Hi! It seems like it is not there yet in v1.0.1. Can it be expected in v1.0.2 and when it is coming out? In absence of such a capability does the ODMG layer handle the recursive references for updates in v1.0.1? How about PB layer queries (with in an ODMG tx) for an object that has references to a collection of objects that in turn have references back to it? Any response shall be greatly appreciated. Thanks Ashish - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ClassDescriptor.updateLockingValues() implementation in 1.0.1vs. 0.6
We are using Oracle JDBC, but I haven't seen any of our timestamps produce more
precision than millisecond. This is probably why it works fine for us.
Perhaps you could truncate the time down to millisecond or microsecond
(ts.setNanos(((int) (ts.getNanos() / 100)) * 100)) instead of calling
setNanos(0)?
Paul
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 16, 2004 6:22 PM
To: OJB Users List
Subject: Re: ClassDescriptor.updateLockingValues() implementation in 1.0.1vs.
0.6
Hi Paul,
here is the log from version 1.88
apply path for optimistic locking problem by Martin Kalén:
Looking at ClassDescriptor.java, lines 949 and 950 in method
updateLockingValues, one sees that the locking timestamp is created using "new
java.sql.Timestamp(long)".
If doing this is seems that at least for Oracle JDBC thin driver, the
naonsecond part of the Timestamp can be initialized to values != 0.
Since Oracle TIMESTAMP does not have nanosecond precision, the value for
comparision when reading back from the DB will _always_ have
Timestamp.getNanos() == 0.
Hence; the timestamp in memory and the comparision value read from the db will
differ and OptimisticLockingException thrown were it should not.
>
> There was no comment added, so I am curious as to the reasoning for this
> change. I have commented it out and it seems to have no adverse effects on
> our application test cases (and fixes the failing one).
>
But after reading the java.sql.Timestamp javadoc I tend to agree with you. Will
try to add an test case for this issue. Which DB do you use?
regards,
Armin
Nase, Paul R. wrote:
> Hi,
>
> I am currently attempting to migrate our application from 0.6 to 1.0.1. One
> of our test cases caught a small change in the ClassDescriptor implementation
> in which I am confused as to why this would need to be done.
> Here is the original code (updateLockingValues()):
> // Timestamp
> else if (f.getType() == Timestamp.class)
> {
> long newCv = (new Date()).getTime();
> f.set(obj, new Timestamp(newCv));
> }
>
> Here is the new code (updateLockingValues()):
> // Timestamp
> else if (f.getType() == Timestamp.class)
> {
> long newCv = (new Date()).getTime();
> Timestamp ts = new Timestamp(newCv);
> ts.setNanos(0);
> f.set(obj, ts);
> }
>
> When the setNanos(0) is called, this is basically truncating the timestamp to
> 1 second precision. Is this needed for some reason? Seems like a dangerous
> change, as more than a couple of updates could possibly occur within a 1
> second timeframe.
>
> There was no comment added, so I am curious as to the reasoning for this
> change. I have commented it out and it seems to have no adverse effects on
> our application test cases (and fixes the failing one).
>
> Paul
>
>
> -
> 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]
Re: ClassDescriptor.updateLockingValues() implementation in 1.0.1 vs. 0.6
Hi Paul,
here is the log from version 1.88
apply path for optimistic locking problem by Martin Kalén:
Looking at ClassDescriptor.java, lines 949 and 950 in method
updateLockingValues,
one sees that the locking timestamp is created using "new
java.sql.Timestamp(long)".
If doing this is seems that at least for Oracle JDBC thin driver, the
naonsecond
part of the Timestamp can be initialized to values != 0.
Since Oracle TIMESTAMP does not have nanosecond precision, the value for
comparision
when reading back from the DB will _always_ have Timestamp.getNanos() == 0.
Hence; the timestamp in memory and the comparision value read from the
db will differ
and OptimisticLockingException thrown were it should not.
>
> There was no comment added, so I am curious as to the reasoning for
this change. I have commented it out and it seems to have no adverse
effects on our application test cases (and fixes the failing one).
>
But after reading the java.sql.Timestamp javadoc I tend to agree with
you. Will try to add an test case for this issue. Which DB do you use?
regards,
Armin
Nase, Paul R. wrote:
Hi,
I am currently attempting to migrate our application from 0.6 to 1.0.1. One of
our test cases caught a small change in the ClassDescriptor implementation in
which I am confused as to why this would need to be done.
Here is the original code (updateLockingValues()):
// Timestamp
else if (f.getType() == Timestamp.class)
{
long newCv = (new Date()).getTime();
f.set(obj, new Timestamp(newCv));
}
Here is the new code (updateLockingValues()):
// Timestamp
else if (f.getType() == Timestamp.class)
{
long newCv = (new Date()).getTime();
Timestamp ts = new Timestamp(newCv);
ts.setNanos(0);
f.set(obj, ts);
}
When the setNanos(0) is called, this is basically truncating the timestamp to 1
second precision. Is this needed for some reason? Seems like a dangerous
change, as more than a couple of updates could possibly occur within a 1 second
timeframe.
There was no comment added, so I am curious as to the reasoning for this
change. I have commented it out and it seems to have no adverse effects on our
application test cases (and fixes the failing one).
Paul
-
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]
ClassDescriptor.updateLockingValues() implementation in 1.0.1 vs. 0.6
Hi,
I am currently attempting to migrate our application from 0.6 to 1.0.1. One of
our test cases caught a small change in the ClassDescriptor implementation in
which I am confused as to why this would need to be done.
Here is the original code (updateLockingValues()):
// Timestamp
else if (f.getType() == Timestamp.class)
{
long newCv = (new Date()).getTime();
f.set(obj, new Timestamp(newCv));
}
Here is the new code (updateLockingValues()):
// Timestamp
else if (f.getType() == Timestamp.class)
{
long newCv = (new Date()).getTime();
Timestamp ts = new Timestamp(newCv);
ts.setNanos(0);
f.set(obj, ts);
}
When the setNanos(0) is called, this is basically truncating the timestamp to 1
second precision. Is this needed for some reason? Seems like a dangerous
change, as more than a couple of updates could possibly occur within a 1 second
timeframe.
There was no comment added, so I am curious as to the reasoning for this
change. I have commented it out and it seems to have no adverse effects on our
application test cases (and fixes the failing one).
Paul
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [QUICKSTART] - A OJB quickstart similar to hibernate
hi ilias, you have to add a proper manifest-file to your jar. see http://ant.apache.org/manual/index.html jakob Ilias Lazaridis schrieb: Ilias Lazaridis wrote: [...] An ant target "jar" is available. Within Netbeans 4.0, i've started this. Try to execute the produced jar: J:\pj\ojbeval\ojb-blank\target>java -jar my-project.jar Failed to load Main-Class manifest attribute from my-project.jar [...] Can one tell me the necessary modifications for the build.xml to make the produced jar file start correctly? . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ojb junit tests errors + on different dbs
Hi Frank, [EMAIL PROTECTED] wrote: I Have a question to the junit testsuite and ojb. is it normal, that so many tests fail: junit-no-compile-no-prepare: [junit] Running org.apache.ojb.broker.AllTests [junit] Tests run: 436, Failures: 3, Errors: 66, Time elapsed: 147,875 sec [junit] Test org.apache.ojb.broker.AllTests FAILED i'm running ojb 1.01 and oracle8 is there and db that runs all tests without errors? All tests should pass with hsql. I can't test against oracle, but Martin Kalén (OJB/oracle expert) run the test suite against oracle9, see http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=1734125 is ervery one using mysql? (me too, most things work fine with mysql, but in my current project I depend on oracle 8) Currently I cannot use ojb on oracle 8, cause a very essential feature (described some mails before) will not work correct: "Assigned to the mapping associations i.e. I get a null value because the n-side objects (or single object for 1:1) are not materialized. I found this oracle9i thread http://www.mail-archive.com/ojb-user@db.apache.org/msg09794.html do you think the same? This issue is fixed (as I said above, Martin pass the test suite). regards, Armin thanks! Frank - 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: How to markup for xdoclet inheritance structure?
Wow nice catch! I didn't even notice, I guess I was looking quick. I
wonder if it was Wallace's copy paste problem.
R
On 11/16/04 2:19 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> I haven't successfully used xdoclet, but if it is like javadoc, you need to
> start the comments with double asterisk: /** not just /*.
>
> my 2 cents
> CQ
>
> Original Message:
> -
> From: Gelhar, Wallace Joseph [EMAIL PROTECTED]
> Date: Tue, 16 Nov 2004 10:56:09 -0600
> To: [EMAIL PROTECTED]
> Subject: RE: How to markup for xdoclet inheritance structure?
>
>
> Actually this is the logger output as well. Where do I start to debug
> this?
>
> repository-files:
> java.util.logging.ErrorManager: 2
> java.lang.NullPointerException
> at org.apache.tools.ant.Project.getThreadTask(Project.java:1985)
> at org.apache.tools.ant.Project.demuxOutput(Project.java:1086)
> at
> org.apache.tools.ant.DemuxOutputStream.processBuffer(DemuxOutputStream.j
> ava:172)
> at
> org.apache.tools.ant.DemuxOutputStream.write(DemuxOutputStream.java:147)
> at
> org.apache.tools.ant.DemuxOutputStream.write(DemuxOutputStream.java:241)
> at java.io.PrintStream.write(PrintStream.java:258)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:40
> 4)
> at
> sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
> at java.util.logging.StreamHandler.flush(StreamHandler.java:224)
> at
> java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
> at java.util.logging.Logger.log(Logger.java:424)
> at java.util.logging.Logger.doLog(Logger.java:446)
> at java.util.logging.Logger.logp(Logger.java:562)
> at
> org.apache.commons.logging.impl.Jdk14Logger.log(Jdk14Logger.java:91)
> at
> org.apache.commons.logging.impl.Jdk14Logger.info(Jdk14Logger.java:162)
> at xdoclet.XDocletMain.start(XDocletMain.java:47)
> at xdoclet.DocletTask.start(DocletTask.java:462)
> at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:110)
> at
> org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
> at org.apache.tools.ant.Task.perform(Task.java:364)
> at org.apache.tools.ant.Target.execute(Target.java:301)
> at org.apache.tools.ant.Target.performTasks(Target.java:328)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
> at
> org.apache.tools.ant.Project.executeTargets(Project.java:1063)
> at
> org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:1
> 78)
> at
> org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:2
> 52)
> at
> org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
> Generating ojb repository descriptor (repository_user.xml)
> Type uwec.fpm.persistence.report.Report
> Type uwec.fpm.persistence.report.ReportParameterValueImpl
> Type uwec.fpm.persistence.report.ReportParameterValue
> Type uwec.fpm.persistence.report.ReportField
> Type uwec.fpm.persistence.report.ReportParameterImpl
> Type uwec.fpm.persistence.PersistentObjectImpl
> Type uwec.fpm.persistence.report.ReportFieldType
> Type uwec.fpm.persistence.report.ReportParameter
> Type uwec.fpm.persistence.PersistentObject
> Processed 9 types
> Warning: The class uwec.fpm.persistence.PersistentObject has no primary
> key
> Warning: The class uwec.fpm.persistence.PersistentObjectImpl has no
> primary key
> Warning: The class uwec.fpm.persistence.report.ReportParameterImpl has
> no primary key
> Warning: The class uwec.fpm.persistence.report.ReportParameterValue has
> no primary key
> Warning: The class uwec.fpm.persistence.report.ReportParameterValueImpl
> has no primary key
> Processed 9 types
>
>
> -Original Message-
> From: Gelhar, Wallace Joseph
> Sent: Tuesday, November 16, 2004 10:24 AM
> To: OJB Users List
>
> Subject: RE: How to markup for xdoclet inheritance structure?
>
> What is wrong with this markup. I've followed your advice and allowed
> xdoclet to generate a table for the persistent base class (even though
> the fields are in each concrete classes table), but this fails to
> produce *any* fields in the repository. Do I really have to duplicate
> each @ojb.field tag FIVE times for each property?
>
> BTW, I am using xdoclet-1.2.1, xdoclet-ojb-module-1.2.1, and
> xjavadoc-1.0.3 from CVS.
>
> Any other suggestions?
>
> /**
> * @ojb.class
> */
> public interface PersistentObject {
>
> /*
> * @ojb.field column="ID"
> *jdbc-type="INTEGER"
> *primarykey="true"
> */
> public Integer getId();
> /*
> * @ojb.field column="ID"
> *
RE: How to markup for xdoclet inheritance structure?
I haven't successfully used xdoclet, but if it is like javadoc, you need to
start the comments with double asterisk: /** not just /*.
my 2 cents
CQ
Original Message:
-
From: Gelhar, Wallace Joseph [EMAIL PROTECTED]
Date: Tue, 16 Nov 2004 10:56:09 -0600
To: [EMAIL PROTECTED]
Subject: RE: How to markup for xdoclet inheritance structure?
Actually this is the logger output as well. Where do I start to debug
this?
repository-files:
java.util.logging.ErrorManager: 2
java.lang.NullPointerException
at org.apache.tools.ant.Project.getThreadTask(Project.java:1985)
at org.apache.tools.ant.Project.demuxOutput(Project.java:1086)
at
org.apache.tools.ant.DemuxOutputStream.processBuffer(DemuxOutputStream.j
ava:172)
at
org.apache.tools.ant.DemuxOutputStream.write(DemuxOutputStream.java:147)
at
org.apache.tools.ant.DemuxOutputStream.write(DemuxOutputStream.java:241)
at java.io.PrintStream.write(PrintStream.java:258)
at
sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:40
4)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at java.util.logging.StreamHandler.flush(StreamHandler.java:224)
at
java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
at java.util.logging.Logger.log(Logger.java:424)
at java.util.logging.Logger.doLog(Logger.java:446)
at java.util.logging.Logger.logp(Logger.java:562)
at
org.apache.commons.logging.impl.Jdk14Logger.log(Jdk14Logger.java:91)
at
org.apache.commons.logging.impl.Jdk14Logger.info(Jdk14Logger.java:162)
at xdoclet.XDocletMain.start(XDocletMain.java:47)
at xdoclet.DocletTask.start(DocletTask.java:462)
at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:110)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:301)
at org.apache.tools.ant.Target.performTasks(Target.java:328)
at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1063)
at
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:1
78)
at
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:2
52)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
Generating ojb repository descriptor (repository_user.xml)
Type uwec.fpm.persistence.report.Report
Type uwec.fpm.persistence.report.ReportParameterValueImpl
Type uwec.fpm.persistence.report.ReportParameterValue
Type uwec.fpm.persistence.report.ReportField
Type uwec.fpm.persistence.report.ReportParameterImpl
Type uwec.fpm.persistence.PersistentObjectImpl
Type uwec.fpm.persistence.report.ReportFieldType
Type uwec.fpm.persistence.report.ReportParameter
Type uwec.fpm.persistence.PersistentObject
Processed 9 types
Warning: The class uwec.fpm.persistence.PersistentObject has no primary
key
Warning: The class uwec.fpm.persistence.PersistentObjectImpl has no
primary key
Warning: The class uwec.fpm.persistence.report.ReportParameterImpl has
no primary key
Warning: The class uwec.fpm.persistence.report.ReportParameterValue has
no primary key
Warning: The class uwec.fpm.persistence.report.ReportParameterValueImpl
has no primary key
Processed 9 types
-Original Message-
From: Gelhar, Wallace Joseph
Sent: Tuesday, November 16, 2004 10:24 AM
To: OJB Users List
Subject: RE: How to markup for xdoclet inheritance structure?
What is wrong with this markup. I've followed your advice and allowed
xdoclet to generate a table for the persistent base class (even though
the fields are in each concrete classes table), but this fails to
produce *any* fields in the repository. Do I really have to duplicate
each @ojb.field tag FIVE times for each property?
BTW, I am using xdoclet-1.2.1, xdoclet-ojb-module-1.2.1, and
xjavadoc-1.0.3 from CVS.
Any other suggestions?
/**
* @ojb.class
*/
public interface PersistentObject {
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public Integer getId();
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public void setId(Integer id);
...
}
/**
* @ojb.class
*/
public abstract class PersistentObjectImpl implements PersistentObject {
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
protected Integer id;
/*
* @ojb.field column="ID"
*jd
RE: [SUGGESTION] - S01 - Website.MainPage & QuickStarts
Thanks for proposing this! I have been lurking here for quite a while and now I am actually writing my web app. I seem to get stuck on creating the repository. I go to look at the test source and can't find it, I run the junit tests and it takes 2 hours to finally use all the memory on my computer and give up, ... OJBC has been a help to ease into this. I like the idea of working only in my java class and being able to create sql for creating my backend and the repository file (and documentation) from the one source. It is pretty easy to find out how to include @ojb tags, but not so clear how to get my sql and repository from there. I have given a few small suggestions inline below. clq Original Message: - From: Ilias Lazaridis [EMAIL PROTECTED] Date: Mon, 15 Nov 2004 20:18:08 +0200 To: [EMAIL PROTECTED] Subject: [SUGGESTION] - S01 - Website.MainPage & QuickStarts [please, if you like to comment on this, write inline within the contex] - The below document is a draft-version proposal for the main-page of the OJB website. It focuses on two points: - getting visitors to try it! - pointing out OJB's major top-level strenghts! The suggested quick-starts would allow: - newcomers : to use OJB to quickly explore real JAVA OOAD in conjunction with IDE's like NetBeans. - evaluators: to check OJB quickly without [** affection of do you mean affecting? **] the running developement system I can create those quick-start-projects. Assistance from OJB-team needed: mostly a few answers to questions which I raise during the creation process [within the user list]. The main goal is to make the tutorials modular (stepwise increase of complexity), transparent (newcomer-safe, e.g. no domain-knowledge necessary) and efficient (quick introduction). - [A question: is it possible to retrieve older versions of the OJB website, e.g. to track changes?] - OJB ObJectRelationalBridge - Scalable Transparent Persistence for Java Objects OJB is easy: - Don't read documentations - start with trying it: - The OJB team cares about your time - 5 min: download - self-contained: everything needed within one folder - no affection on current development system - evaluate OJB without risk - run the samples and explore its sources - netbeans 4.0 project included - eclipse 3.0 project included - 10min: create your first real application - define a java class - declare it as persistent - build *everything*, including database, with a single command - within your IDE - or from the command line - run your first application - create, retrieve, update, erase objects - 20min: extend your first app with relations (1:1, n:1, 1:n, m:n) - explore real OOAD with JAVA & OJB - stepwise define 4 more java classes - attach them to the first class - explore incremental design capabilities of OJB - watch OJB's schema update mechanisms do the work for you - 10min: migrate you first app to another database (MySQL) - watch OJB's schema migration mechanisms work for you OJB is pure: - pure java - enables pure OOAD OJB is scalable: - use it within[g] embedded applications - up to enterprise scale distributed applications OJB is powerfull: - fine-tune your application, with high detail grade of control - field proven Cache & distributed systems OJB is flexible in RDBMS - HSQL (already bundled), MySQL, ... OJB is flexible in API's [does not bind you to proprietary technology]: - full ODMG 3.0 compliant API - later migration to ODMG driven OODBMS systems is possible - full ODMG 3.0 standard OQL (Object Query Language) - later migration to major OODBMS systems, without change of OQL code - ODMG available for other OO languages, too (e.g. C++) - allows design of highly speed-critical code with C++/ASM bridge - [disclosure: ] - full JDO 1.0 compliant API - later migration to JDO (RDBMS/OODBMS) systems is possible - based on JDO Reference Implementation - highest compatibility - [disclosure: performancy penalty of ~XX%, see performance notes] - native implementations sheduled for OJB 2.0 - an OTM [** spell it out, please. I already have trouble with ODMG and JDO, what is OTM? **] API (ODMG / JDO common functionality) - if you are still undecided which one to use - a low-level OJB API (PersistenceBroker) - all other api's are based on this - allows definition of your in-house API's - e.g. when creating specific Frameworks. . [how about some thoughts on using with struts? Seems my comments are fewer and farther between than I thought. I want to help make this useful and popular project. I hope this made sense.] -- http://lazaridis.com - To unsubscribe, e-mail:
RE: OJB, Optimistic Locking, and multiple threads
> We are currently using OJB, with a single JVM, but we are planning on
> going to a clustered environment. I was doing some testing of just
> one class with a few fields that maps to one table. Instead of
> running multiple applications on multiple JVMs, I thought it would be
> easier to have one application spawn several threads, and each of the
> threads persist a different object. If I run one Thread everything
> works fine, but when I increase the number of threads I get an
> OptimisticLockException. I followed the clustering how-to to get
> everything set up. Should this work the same with multiple threads as
> it would with multiple JVMs? If so can someone let me know what I am
> doing wrong?
>
> I'll put the relevant code/mapping below. Let me know if anything
> else would be helpful to see.
>
> Thanks,
> Wes
>
> The servlet class:
> public class WesServlet extends HttpServlet {
> private static final int THREAD_COUNT = 3;
> private static ClientAdder[] threads = null;
>
> protected void doPost(HttpServletRequest req,
> HttpServletResponse resp)
> throws ServletException, IOException {
> threads = new ClientAdder[THREAD_COUNT];
>
> PrintWriter writer = resp.getWriter();
>
> writer.println("Mysql");
> writer.println("Mysql OL Testing.");
> System.err.println("SERVLET: Calling " +
> THREAD_COUNT + " threads.");
> for(int i = 0; i < THREAD_COUNT; i++){
> ClientAdder ca = new ClientAdder();
> System.err.println("SERVELET: Creating
> thread " + i);
> threads[i] = ca;
> ca.start();
> }
> try {
> for (int i = 0; i < THREAD_COUNT; i++) {
> System.err.println("SERVLET:
> Joining to Thread " + i);
> threads[i].join();
> }
> }
> catch (InterruptedException e) {
> // fall through
> }
> printClientRelationships(req, resp);
> System.err.println("SERVLET: Done.");
>
> writer.println("");
>
> }
>
> protected void doGet(HttpServletRequest req, HttpServletResponse
> resp)
> throws ServletException, IOException {
> doPost(req, resp);
> }
>
> protected void printClientRelationships(HttpServletRequest req,
> HttpServletResponse resp) throws IOException{
> PrintWriter writer = resp.getWriter();
> Query query = new
> QueryByCriteria(ClientRelationship.class, null);
> try{
> PersistenceBroker broker =
> PersistenceBrokerFactory.createPersistenceBroker("default", "user",
> "password");
> Collection allClients =
> broker.getCollectionByQuery(query);
> Iterator iter = allClients.iterator();
> while (iter.hasNext()){
> ClientRelationship cr =
> (ClientRelationship) iter.next();
> writer.println(cr.getName() + "");
> }
> broker.close();
> }
> catch (Throwable t){
> t.printStackTrace();
> }
> }
> }
>
> The Thread class:
> public class ClientAdder extends Thread {
> private static PersistenceBroker broker = null;
> private static String clientName = "";
>
> public void run(){
> //This thread starts a transactions, finds the largest
> name currently in the database,
> //increments the name by one, inserts a new row, and
> then commits the transaction
> System.err.println("THREAD: Running");
> broker =
> PersistenceBrokerFactory.createPersistenceBroker("default", "user",
> "password");
> broker.beginTransaction();
> Query query = new QueryBySQL(ClientRelationship.class,
> "select * from dexa900t order by name");
> Collection c = broker.getCollectionByQuery(query);
> Iterator i = c.iterator();
> System.err.println("THREAD: have collection from DB");
> setClientName("");
> while(i.hasNext()){
> ClientRelationship bleh = (ClientRelationship)
> i.next();
> if(bleh.getName().compareTo(getClientName()) >
> 0){
> setClientName(bleh.getName());
> }
> }
> if((getClientName() == null) ||
> getClientName().equals("")){
> System.err.
Re: Error with ConnectionManagerImpl...
Hi Fernando,
if you use OJB within a session bean, please set
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactorySyncImpl
in OJB.properties file. In managed environment it's only allowed to use
JTA-tx, so use container managed tx or UserTransation.
http://db.apache.org/ojb/docu/guides/deployment.html#%0A
regards,
Armin
Fernando Bernardino wrote:
Hi everybody!
I'm using OJB 1.0.1 with JBoss 3.2.5, and using OJB via JNDI. It seems to be
working fine, but after I start a transaction:
protected PersistenceBroker broker;
public BaseDAO(){
try{
broker =
PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker();
}catch(Exception e){
e.printStackTrace();
}
}
.
broker.beginTransaction();
broker.store(object);
.
the ERROR is printed in the JBoss console. I can store the object, but this
error still happening.
16:26:53,296 INFO [STDOUT] [org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] ERROR:
16:26:53,296 INFO [STDOUT] Release connection: connection is in local transaction, missing 'localCommit' or 'localRollback' call - try to rollback the connection
How can i fix this problem?
OJB.propeties:
#
# PersistenceBrokerFactory / PersistenceBroker
#
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
#
# ConnectionFactory / Default ConnectionPool
#
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
#
# ConnectionManager
#
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
#
# JdbcAccess
#
JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
#
TATransactionManagerClass=org.apache.ojb.odmg.transaction.JBossTransactionManagerFactory
Need to show something more?
Thanks for your help.
___
| Fernando G. Bernardino
| .COM Tecnologia
| Desenvolvimento e Consultoria
| 8802-0104 -- 224-1921
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Error with ConnectionManagerImpl...
Hi everybody!
I'm using OJB 1.0.1 with JBoss 3.2.5, and using OJB via JNDI. It seems to be
working fine, but after I start a transaction:
protected PersistenceBroker broker;
public BaseDAO(){
try{
broker =
PersistenceBrokerFactoryFactory.instance().defaultPersistenceBroker();
}catch(Exception e){
e.printStackTrace();
}
}
.
broker.beginTransaction();
broker.store(object);
.
the ERROR is printed in the JBoss console. I can store the object, but this
error still happening.
16:26:53,296 INFO [STDOUT]
[org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] ERROR:
16:26:53,296 INFO [STDOUT] Release connection: connection is in local
transaction, missing 'localCommit' or 'localRollback' call - try to rollback
the connection
How can i fix this problem?
OJB.propeties:
#
# PersistenceBrokerFactory / PersistenceBroker
#
PersistenceBrokerFactoryClass=org.apache.ojb.broker.core.PersistenceBrokerFactoryDefaultImpl
#
# ConnectionFactory / Default ConnectionPool
#
ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl
#
# ConnectionManager
#
ConnectionManagerClass=org.apache.ojb.broker.accesslayer.ConnectionManagerImpl
#
# JdbcAccess
#
JdbcAccessClass=org.apache.ojb.broker.accesslayer.JdbcAccessImpl
#
TATransactionManagerClass=org.apache.ojb.odmg.transaction.JBossTransactionManagerFactory
Need to show something more?
Thanks for your help.
___
| Fernando G. Bernardino
| .COM Tecnologia
| Desenvolvimento e Consultoria
| 8802-0104 -- 224-1921
RE: How to markup for xdoclet inheritance structure?
Actually this is the logger output as well. Where do I start to debug
this?
repository-files:
java.util.logging.ErrorManager: 2
java.lang.NullPointerException
at org.apache.tools.ant.Project.getThreadTask(Project.java:1985)
at org.apache.tools.ant.Project.demuxOutput(Project.java:1086)
at
org.apache.tools.ant.DemuxOutputStream.processBuffer(DemuxOutputStream.j
ava:172)
at
org.apache.tools.ant.DemuxOutputStream.write(DemuxOutputStream.java:147)
at
org.apache.tools.ant.DemuxOutputStream.write(DemuxOutputStream.java:241)
at java.io.PrintStream.write(PrintStream.java:258)
at
sun.nio.cs.StreamEncoder$CharsetSE.writeBytes(StreamEncoder.java:336)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlushBuffer(StreamEncoder.java:40
4)
at
sun.nio.cs.StreamEncoder$CharsetSE.implFlush(StreamEncoder.java:408)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:152)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:213)
at java.util.logging.StreamHandler.flush(StreamHandler.java:224)
at
java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88)
at java.util.logging.Logger.log(Logger.java:424)
at java.util.logging.Logger.doLog(Logger.java:446)
at java.util.logging.Logger.logp(Logger.java:562)
at
org.apache.commons.logging.impl.Jdk14Logger.log(Jdk14Logger.java:91)
at
org.apache.commons.logging.impl.Jdk14Logger.info(Jdk14Logger.java:162)
at xdoclet.XDocletMain.start(XDocletMain.java:47)
at xdoclet.DocletTask.start(DocletTask.java:462)
at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:110)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:269)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.tools.ant.Target.execute(Target.java:301)
at org.apache.tools.ant.Target.performTasks(Target.java:328)
at org.apache.tools.ant.Project.executeTarget(Project.java:1215)
at
org.apache.tools.ant.Project.executeTargets(Project.java:1063)
at
org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:1
78)
at
org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:2
52)
at
org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)
Generating ojb repository descriptor (repository_user.xml)
Type uwec.fpm.persistence.report.Report
Type uwec.fpm.persistence.report.ReportParameterValueImpl
Type uwec.fpm.persistence.report.ReportParameterValue
Type uwec.fpm.persistence.report.ReportField
Type uwec.fpm.persistence.report.ReportParameterImpl
Type uwec.fpm.persistence.PersistentObjectImpl
Type uwec.fpm.persistence.report.ReportFieldType
Type uwec.fpm.persistence.report.ReportParameter
Type uwec.fpm.persistence.PersistentObject
Processed 9 types
Warning: The class uwec.fpm.persistence.PersistentObject has no primary
key
Warning: The class uwec.fpm.persistence.PersistentObjectImpl has no
primary key
Warning: The class uwec.fpm.persistence.report.ReportParameterImpl has
no primary key
Warning: The class uwec.fpm.persistence.report.ReportParameterValue has
no primary key
Warning: The class uwec.fpm.persistence.report.ReportParameterValueImpl
has no primary key
Processed 9 types
-Original Message-
From: Gelhar, Wallace Joseph
Sent: Tuesday, November 16, 2004 10:24 AM
To: OJB Users List
Subject: RE: How to markup for xdoclet inheritance structure?
What is wrong with this markup. I've followed your advice and allowed
xdoclet to generate a table for the persistent base class (even though
the fields are in each concrete classes table), but this fails to
produce *any* fields in the repository. Do I really have to duplicate
each @ojb.field tag FIVE times for each property?
BTW, I am using xdoclet-1.2.1, xdoclet-ojb-module-1.2.1, and
xjavadoc-1.0.3 from CVS.
Any other suggestions?
/**
* @ojb.class
*/
public interface PersistentObject {
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public Integer getId();
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public void setId(Integer id);
...
}
/**
* @ojb.class
*/
public abstract class PersistentObjectImpl implements PersistentObject {
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
protected Integer id;
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public Integer getId() { return id; }
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public void setId(Integer id) { this.id = id; } ...
}
/**
* @ojb.class
*/
public interface Repor
Re: How to markup for xdoclet inheritance structure?
Well the docs say you only need to set it on either the get or set. Not
both. I put it on the get.
Also, I believe (haven't tried yet), since java docs are inherited by the
impl, you only need to set it there.
Third you need to put a little more than that in your class definition
otherwise xdoclet has no idea what your table is called, especially if you
intend to use Interfaces. The following below should figure it all out for
you:
@ojb.class table="cdpcno_projects" determine-extents="true"
include-inherited="true" generate-table-info="true" refresh="true"
For your ID fields you might want to consider something like this:
@ojb.field indexed="true" column="project_id" jdbc-type="INTEGER"
primarykey="true" autoincrement="ojb"
Hth more.
R
On 11/16/04 11:23 AM, "Gelhar, Wallace Joseph" <[EMAIL PROTECTED]> wrote:
> What is wrong with this markup. I've followed your advice and allowed
> xdoclet to generate a table for the persistent base class (even though
> the fields are in each concrete classes table), but this fails to
> produce *any* fields in the repository. Do I really have to duplicate
> each @ojb.field tag FIVE times for each property?
>
> BTW, I am using xdoclet-1.2.1, xdoclet-ojb-module-1.2.1, and
> xjavadoc-1.0.3 from CVS.
>
> Any other suggestions?
>
> /**
> * @ojb.class
> */
> public interface PersistentObject {
>
> /*
> * @ojb.field column="ID"
> *jdbc-type="INTEGER"
> *primarykey="true"
> */
> public Integer getId();
> /*
> * @ojb.field column="ID"
> *jdbc-type="INTEGER"
> *primarykey="true"
> */
> public void setId(Integer id);
> ...
> }
>
> /**
> * @ojb.class
> */
> public abstract class PersistentObjectImpl implements PersistentObject {
>
> /*
> * @ojb.field column="ID"
> *jdbc-type="INTEGER"
> *primarykey="true"
> */
> protected Integer id;
> /*
> * @ojb.field column="ID"
> *jdbc-type="INTEGER"
> *primarykey="true"
> */
> public Integer getId() { return id; }
> /*
> * @ojb.field column="ID"
> *jdbc-type="INTEGER"
> *primarykey="true"
> */
> public void setId(Integer id) { this.id = id; }
> ...
> }
>
> /**
> * @ojb.class
> */
> public interface ReportParameterValue extends PersistentObject {
> /*
> * @ojb.field column="ParameterValue"
> */
> public String getValue();
> /*
> * @ojb.field column="ParameterValue"
> */
> public void setValue(String value);
> }
>
> /**
> * @ojb.class table="tblRptReportParameterValue"
> * @ojb.field name="reportParameterID"
> *column="ReportParameterID"
> *jdbc-type="INTEGER"
> */
> public class ReportParameterValueImpl extends PersistentObjectImpl
> implements ReportParameterValue {
> /*
> * @ojb.field column="ParameterValue"
> */
> protected String value;
> ...
> /*
> * @ojb.field column="ParameterValue"
> */
> public String getValue() { return value; }
> /*
> * @ojb.field column="ParameterValue"
> */
> public void setValue(String value) { this.value = value; }
> }
>
> This is the repository it produces:
>
>
>
>
> class="uwec.fpm.persistence.PersistentObject"
> table="PersistentObject"
>>
> class-ref="uwec.fpm.persistence.PersistentObjectImpl"/>
> class-ref="uwec.fpm.persistence.report.ReportParameterValue"/>
>
> class="uwec.fpm.persistence.PersistentObjectImpl"
> table="PersistentObjectImpl"
>>
> class-ref="uwec.fpm.persistence.report.ReportParameterValueImpl"/>
>
> class="uwec.fpm.persistence.report.ReportParameterValue"
> table="ReportParameterValue"
>>
> class-ref="uwec.fpm.persistence.report.ReportParameterValueImpl"/>
>
> class="uwec.fpm.persistence.report.ReportParameterValueImpl"
> table="tblRptReportParameterValue"
>>
> name="reportParameterID"
> column="ReportParameterID"
> jdbc-type="INTEGER"
> access="anonymous"
>>
>
>
>
>
> -Original Message-
> From: Thomas Dudziak [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 15, 2004 6:09 PM
> To: OJB Users List
> Subject: Re: How to markup for xdoclet inheritance structure?
>
> Gelhar, Wallace Joseph wrote:
>
>> I am trying to use xdoclet to map an inheritance hierarchy as follows,
>
>> but it fails to include any inherited fields. Any ideas?
>
> The generate-table-info="false" setting disables generation of
> field/reference/collection entries. See here for details:
>
> http://db.apache.org/ojb/docu/guides/xdoclet-module.html#ojb.class
>
> You should also put the ojb.field tags at the getter or setter methods
> in the interfaces because this will cause their definition to be
> inherited in all implementing classes.
>
RE: How to markup for xdoclet inheritance structure?
What is wrong with this markup. I've followed your advice and allowed
xdoclet to generate a table for the persistent base class (even though
the fields are in each concrete classes table), but this fails to
produce *any* fields in the repository. Do I really have to duplicate
each @ojb.field tag FIVE times for each property?
BTW, I am using xdoclet-1.2.1, xdoclet-ojb-module-1.2.1, and
xjavadoc-1.0.3 from CVS.
Any other suggestions?
/**
* @ojb.class
*/
public interface PersistentObject {
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public Integer getId();
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public void setId(Integer id);
...
}
/**
* @ojb.class
*/
public abstract class PersistentObjectImpl implements PersistentObject {
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
protected Integer id;
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public Integer getId() { return id; }
/*
* @ojb.field column="ID"
*jdbc-type="INTEGER"
*primarykey="true"
*/
public void setId(Integer id) { this.id = id; }
...
}
/**
* @ojb.class
*/
public interface ReportParameterValue extends PersistentObject {
/*
* @ojb.field column="ParameterValue"
*/
public String getValue();
/*
* @ojb.field column="ParameterValue"
*/
public void setValue(String value);
}
/**
* @ojb.class table="tblRptReportParameterValue"
* @ojb.field name="reportParameterID"
*column="ReportParameterID"
*jdbc-type="INTEGER"
*/
public class ReportParameterValueImpl extends PersistentObjectImpl
implements ReportParameterValue {
/*
* @ojb.field column="ParameterValue"
*/
protected String value;
...
/*
* @ojb.field column="ParameterValue"
*/
public String getValue() { return value; }
/*
* @ojb.field column="ParameterValue"
*/
public void setValue(String value) { this.value = value; }
}
This is the repository it produces:
-Original Message-
From: Thomas Dudziak [mailto:[EMAIL PROTECTED]
Sent: Monday, November 15, 2004 6:09 PM
To: OJB Users List
Subject: Re: How to markup for xdoclet inheritance structure?
Gelhar, Wallace Joseph wrote:
> I am trying to use xdoclet to map an inheritance hierarchy as follows,
> but it fails to include any inherited fields. Any ideas?
The generate-table-info="false" setting disables generation of
field/reference/collection entries. See here for details:
http://db.apache.org/ojb/docu/guides/xdoclet-module.html#ojb.class
You should also put the ojb.field tags at the getter or setter methods
in the interfaces because this will cause their definition to be
inherited in all implementing classes.
Tom
-
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: Bug identified (was RE: SQLExcpetion)
No problem. I've not come accross many bugs (well serious ones) in OJB, but it's nice to find a hole and hopefully prevent it causing problems for other people. I'm just glad it's sorted now, and our clients app isnt crashing anymore. I agree with your comments on cleaning up a bit better. The code seems to do better if transactions are used, but much of my code doesnt have any requirement for them. Thanks, Daniel. > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: 16 November 2004 12:53 > To: OJB Users List > Subject: Re: Bug identified (was RE: SQLExcpetion) > > > Hi Daniel, > > many thanks for your detailed description and suggestion. > > > > > The solution is in ConnectionManagerImpl.getConnection method. The > code is > > already there, but commented out: > > > >>// if (con == null || !isAlive(con)) > >>// isAlive check, how do we react if false and we in tx? > >>// create a new connection isn't the right way I think. > >>if (con == null) > > > > > > I think this code should be applied - or at the very least, should be > > modified and applied if not inside a transaction: > > > > if (con == null || (!isInLocalTransaction() && !isAlive(con)) ) > > > > I will check in your patch ASAP. Additionally I think we should release > the closed connection instance and I will do a minor refactoring of > CollectionProxyDefaultImpl to handle the used PB instance more strict. > > > regards, > Armin > > > Daniel Perry wrote: > > > I believe that I have solved this problem, and that there is a > bug in OJB. > > I cannot be sure, but with the fix, the app has been running > for 10 days now > > with no reported errors. > > > > It seems that in certain circumstances an old connection will > be reused, and > > it will not be validated (or checked for being alive). > > > > The following conditions are required for the error to occur : > > 1. An object is cached (it will only happen with a long term cache - eg > > ObjectCacheDefaultImpl) > > 2. The object has been cached for long enough for the database > connection > > that was used to load it has expired > > 3. The object was loaded from outside a transaction (or > possibly also inside > > a very long living transaction) > > 4. A collection proxy (not sure if it affects other proxies) is > materialised > > from within this > > object > > > > What seems to happen, is the connection which was used to load > the object is > > held onto, and when the collection is materialised it reuses this stale > > connection and crashes out. It might also be caused if it has > already been > > materialised and refresh=true - not sure how that works though. > > > > This bug will only affect people using OJB in accordance with the above > > criteria. ObjectCachePerBrokerImpl shouldn't be affected. Also the bug > > wont apply if using transactions - as when it is closed it drops the > > connection. > > > > The solution is in ConnectionManagerImpl.getConnection method. > The code is > > already there, but commented out: > > > >>// if (con == null || !isAlive(con)) > >>// isAlive check, how do we react if false and we in tx? > >>// create a new connection isn't the right way I think. > >>if (con == null) > > > > > > I think this code should be applied - or at the very least, should be > > modified and applied if not inside a transaction: > > > > if (con == null || (!isInLocalTransaction() && !isAlive(con)) ) > > > > Daniel. > > > > > >>-Original Message- > >>From: Daniel Perry [mailto:[EMAIL PROTECTED] > >>Sent: 02 November 2004 11:14 > >>To: OJB Users List > >>Subject: RE: SQLExcpetion > >> > >> > >>Once again our app has started getting these errors (see trace > below). It > >>seems to be happening after several days of operation. > >> > >>The problem always seems to happen when iterating over a proxied > >>collection > >>in a jsp (using jakarta JSTL c:forEach tag). > >> > >>See comments below: > >> > >> > >>>Is the error always caused by the same class > >>> > >>> at > >>> org.apache.taglibs.standard.tag.common.core.ForEachSupport.toForE > >>> >>> > >>> >>>achIterator > >>> > >>>or always caused when materialized a proxied collection? > >> > >>Yes it's caused by that same class, but not always from the same jsp. > >> > >>But it's also always when proxied collections are materialised. > >> > >> > >>>Does the error occur when OJB materialize a class with clob/blob or > >>>binary/object field? > >>> > >> > >>Dont think so. > >> > >> > Is there a way for me to clear the connection pool? > >>> > >>>You can try > >>>ConnectionFactoryFactory.createConnectionFactory().releaseAllRe > sources() > >>>CFF is a singleton. This call clear the used pool and close all > >>>connections of the pool (connections in use will be ignored AFAIK) > >>> > >>>Or extend ConnectionFactoryPooledImpl and add your own > >> > >>monitoring methods. > >> > >> > >>I've tried clearing t
Re: [SUGGESTION] - S02 - Answering behaviour on this forum
Hi, Ilias. Good to see you here (too). I'm following OJB project sice beta days, and I just reporting that some threads are not answered because they are in the docs AND/OR are avaliable in past threads. My experience at OJB mailing lists is that valid threads, and that are not already answered in past, are rapidly answered. As always I have opportunity, I congrat the OJB team due their fast responses and solutions, and to be open to discuss constructivelly even was my personal mistakes. Best regards, Edson Richter Ilias Lazaridis escreveu: I've noticed several threads, which remained unanswered. This could imply to visitors that the product OJB is death (or not yet alive) You should ensure that every request is answered, If possible with a pointer to some resource. . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bug identified (was RE: SQLExcpetion)
Hi Daniel, many thanks for your detailed description and suggestion. > > The solution is in ConnectionManagerImpl.getConnection method. The code is > already there, but commented out: > >>// if (con == null || !isAlive(con)) >>// isAlive check, how do we react if false and we in tx? >>// create a new connection isn't the right way I think. >>if (con == null) > > > I think this code should be applied - or at the very least, should be > modified and applied if not inside a transaction: > > if (con == null || (!isInLocalTransaction() && !isAlive(con)) ) > I will check in your patch ASAP. Additionally I think we should release the closed connection instance and I will do a minor refactoring of CollectionProxyDefaultImpl to handle the used PB instance more strict. regards, Armin Daniel Perry wrote: I believe that I have solved this problem, and that there is a bug in OJB. I cannot be sure, but with the fix, the app has been running for 10 days now with no reported errors. It seems that in certain circumstances an old connection will be reused, and it will not be validated (or checked for being alive). The following conditions are required for the error to occur : 1. An object is cached (it will only happen with a long term cache - eg ObjectCacheDefaultImpl) 2. The object has been cached for long enough for the database connection that was used to load it has expired 3. The object was loaded from outside a transaction (or possibly also inside a very long living transaction) 4. A collection proxy (not sure if it affects other proxies) is materialised from within this object What seems to happen, is the connection which was used to load the object is held onto, and when the collection is materialised it reuses this stale connection and crashes out. It might also be caused if it has already been materialised and refresh=true - not sure how that works though. This bug will only affect people using OJB in accordance with the above criteria. ObjectCachePerBrokerImpl shouldn't be affected. Also the bug wont apply if using transactions - as when it is closed it drops the connection. The solution is in ConnectionManagerImpl.getConnection method. The code is already there, but commented out: // if (con == null || !isAlive(con)) // isAlive check, how do we react if false and we in tx? // create a new connection isn't the right way I think. if (con == null) I think this code should be applied - or at the very least, should be modified and applied if not inside a transaction: if (con == null || (!isInLocalTransaction() && !isAlive(con)) ) Daniel. -Original Message- From: Daniel Perry [mailto:[EMAIL PROTECTED] Sent: 02 November 2004 11:14 To: OJB Users List Subject: RE: SQLExcpetion Once again our app has started getting these errors (see trace below). It seems to be happening after several days of operation. The problem always seems to happen when iterating over a proxied collection in a jsp (using jakarta JSTL c:forEach tag). See comments below: Is the error always caused by the same class at org.apache.taglibs.standard.tag.common.core.ForEachSupport.toForE >>> >>>achIterator or always caused when materialized a proxied collection? Yes it's caused by that same class, but not always from the same jsp. But it's also always when proxied collections are materialised. Does the error occur when OJB materialize a class with clob/blob or binary/object field? Dont think so. Is there a way for me to clear the connection pool? You can try ConnectionFactoryFactory.createConnectionFactory().releaseAllResources() CFF is a singleton. This call clear the used pool and close all connections of the pool (connections in use will be ignored AFAIK) Or extend ConnectionFactoryPooledImpl and add your own monitoring methods. I've tried clearing the connection pool every hour, so the connections should be fine. I havnt tried clearing the cache... How are connections obtained when cached objects have their proxied collections materialised? (note no transactions are being used) I think an object is being loaded, and stuck in the cache. Days later the object is being used and is having a proxied collection materialised, and this is using the origional connection. From what i can see in the code, a collection proxy obtains a broker, the broker obtains a connection - but (and i might have got the code wrong here) it should reuse the broker it used when it was initally loaded, and then the broker reuses the conenction without checking it isnt closed : ConnectionManagerImpl.getConnection // if (con == null || !isAlive(con)) // isAlive check, how do we react if false and we in tx? // create a new connection isn't the right way I think. if (con == null) This only checks if it has a connection, not if the connection is valid. Maybe i should reinstate the (con == null || !isAlive(con)) ??? Could this be the cause of my problem? or am i way
[SUGGESTION] - S02 - Answering behaviour on this forum
I've noticed several threads, which remained unanswered. This could imply to visitors that the product OJB is death (or not yet alive) You should ensure that every request is answered, If possible with a pointer to some resource. . -- http://lazaridis.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ODMG - delete referenced objects.
On Sun, 14 Nov 2004 17:35:04 +0100, £ukasz Korzybski <[EMAIL PROTECTED]> wrote: >Dnia czwartek, 11 listopada 2004 13:49, Gerhard Grosse napisa³: >> On Wed, 10 Nov 2004 21:26:22 +0100, Grzegorz Pypec <[EMAIL PROTECTED]> >> >> wrote: > >> >> Instead of tx.checkpoint() you can use ((TransactionExt) tx).flush(), >> which flushes all SQL to the DB without commit. >> >> However, normally OJB does a pretty good job in ordering the SQL >> correctly. Could it be that you have some cyclic references in your >> object model (e.g. A->B and B->A)? >> >> Gerhard > >I suppose that after invoking flush(), transaction holds db connection opened >all the time so we can later rollback? > Obviously, the connection has to stay open until the transaction commits. >From JavaDoc: > > "Calling flush flushes persistent object modifications made within the ODMG >transaction since the last checkpoint to the underlying database transaction" > >If so, it is not a good news :) > >Is anyone has similar problem with deleting referenced objects? I have exactly >the same problem as Grzegorz Pypec with ojb1.0.1 nad PostgreSQL 7.4 (jdbc 3.0 >drv). >I can't believe that such essential feature doesn't work. >From looking at the source of ObjectEnvelopeTable.java I see 2 or 3 potential shortcomings of OJB's SQL ordering: - the ordering is based on the modified state of the objects only; therefore if a reference in object A is set to null, OJB does not see that before modification A referenced an object B to be deleted. If B has a corresponding collection mapping containing A, OJB might resolve the dependency from this end, but if there is no collection mapping, no ordering will occur. - 1:n and m:n collections are treated in the same way, although the FK-location in the DB is quite different. - OJB' ordering algorithm is 'greedy' in the sense that once an object modification has been put into the ordered list, it will stay at this position even if later reasons are found that would require to move it to a position further down. If anyone has a better solution... Gerhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ojb 1.0.1 does'nt uses ?
Hi, Thanks for this hint! Roland Ribi > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 16, 2004 10:55 AM > To: OJB Users List > Subject: Re: ojb 1.0.1 does'nt uses ? > > > Hi Roland, > > you have differ between PersistenceBroker pooling (the > PersistenceBrokerFactory pools PB insances) and Connection pooling > (dependent on the used ConnectionFactory implementation connection > pooling could be used). The first one can be configured in > OJB.properties file, the second one in the repository file. > > regards, > Armin > > > Ribi Roland wrote: > > Hi, > > > > Is it correct that ojb 1.0.1 does'nt uses the > settings > > from repository.xml and uses the defaults in OJB.properties instead? > > > > I had the following settings but it did'nt used it: > > > > > maxActive="500" > > maxIdle="100" > > maxWait="-1" > > whenExhaustedAction="2" > > testOnBorrow="true" > > testOnReturn="true" > > testWhileIdle="true" > > timeBetweenEvictionRunsMillis="5000" > > minEvictableIdleTimeMillis="6" > > numTestsPerEvictionRun="5" > > validationQuery="SELECT 1 FROM DUAL"/> > > > > I tried many settings and I had always the same Exceptions > at a specific > > amount of request on my tomcat application. Now I tried to > set this settings > > in the OJB.properties and it works ... > > > > Is it a bug or a feature? :) > > > > > > Roland Ribi > > > > > - > > 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]
Re: ojb 1.0.1 does'nt uses ?
Hi Roland, you have differ between PersistenceBroker pooling (the PersistenceBrokerFactory pools PB insances) and Connection pooling (dependent on the used ConnectionFactory implementation connection pooling could be used). The first one can be configured in OJB.properties file, the second one in the repository file. regards, Armin Ribi Roland wrote: Hi, Is it correct that ojb 1.0.1 does'nt uses the settings from repository.xml and uses the defaults in OJB.properties instead? I had the following settings but it did'nt used it: maxWait="-1" whenExhaustedAction="2" testOnBorrow="true" testOnReturn="true" testWhileIdle="true" timeBetweenEvictionRunsMillis="5000" minEvictableIdleTimeMillis="6" numTestsPerEvictionRun="5" validationQuery="SELECT 1 FROM DUAL"/> I tried many settings and I had always the same Exceptions at a specific amount of request on my tomcat application. Now I tried to set this settings in the OJB.properties and it works ... Is it a bug or a feature? :) Roland Ribi - 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: [SUGGESTION] - S01 - Website.MainPage & QuickStarts
Thomas Dudziak wrote:
Ilias Lazaridis wrote:
The below document is a draft-version proposal for the main-page of
the OJB website.
[...]
The main goal is to make the tutorials modular (stepwise increase of
complexity), transparent (newcomer-safe, e.g. no domain-knowledge
necessary) and efficient (quick introduction).
We always welcome enhancements, especially when it comes to the
documentation, so please post whatever you've got :-)
ok
Btw, best is either textual or in the Forrest format (is really easy,
see the OJB documentation source).
will take a look.
[A question: is it possible to retrieve older versions of the OJB
website, e.g. to track changes?]
Yes, sort of. You've got to check out OJB for a particular date or use
one of the earlier versions (there is a link in the download area) and
build the documentation new ("ant docs").
The website is not available within the CVS directly?
Thus I can point to the websites mainpage?
http://cvs.apache.org/viewcvs/db-ojb/
.
--
http://lazaridis.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [QUICKSTART] - A OJB quickstart similar to hibernate
Jakob Braeuchi wrote: [moved down] Ilias Lazaridis schrieb: Jakob Braeuchi wrote: [...] this is tha batch file i use: @echo off set cp= for %%i in (lib\*.jar) do call cp.bat %%i set CP=classes;%CP% java -cp %CP% org.apache.ojb.tutorial1.Application => missing cp.bat content of cp.bat set CP=%CP%;%1 hi ilias, this is correct! cp.bat is only used add all jars to the classpath jakob ok. I've documented this, for the case someone hits on this thread in future. . -- http://lazaridis.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [QUICKSTART] - A OJB quickstart similar to hibernate
Ilias Lazaridis wrote: [...] An ant target "jar" is available. Within Netbeans 4.0, i've started this. Try to execute the produced jar: J:\pj\ojbeval\ojb-blank\target>java -jar my-project.jar Failed to load Main-Class manifest attribute from my-project.jar [...] Can one tell me the necessary modifications for the build.xml to make the produced jar file start correctly? . -- http://lazaridis.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ojb junit tests errors + on different dbs
I Have a question to the junit testsuite and ojb. is it normal, that so many tests fail: junit-no-compile-no-prepare: [junit] Running org.apache.ojb.broker.AllTests [junit] Tests run: 436, Failures: 3, Errors: 66, Time elapsed: 147,875 sec [junit] Test org.apache.ojb.broker.AllTests FAILED i'm running ojb 1.01 and oracle8 is there and db that runs all tests without errors? is ervery one using mysql? (me too, most things work fine with mysql, but in my current project I depend on oracle 8) Currently I cannot use ojb on oracle 8, cause a very essential feature (described some mails before) will not work correct: >"Assigned to the mapping associations i.e. I get a null value because >the n-side objects (or single object for 1:1) are not materialized. thanks! Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
