objectbridge-developers Mailing List for ObJectRelationalBridge (Page 4)
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers — public list for developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
| 2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Thomas M. <tho...@ho...> - 2002-06-11 18:26:07
|
I used Xerces 2.0.1 Leandro Rodrigo Saad Cruz wrote: > On Tue, 2002-06-11 at 11:04, Mahler Thomas wrote: > >>OJB ships with Crimson. >>Crimson is a bit sloppy with validation etc. >>I also tested release 0.9 with the latest Xerces distribution. > > > Xerces 1 or 2 ? > Xerces 2.0 is not working for me. > 1.4.4 is ok. > > > >>cheers, >> >>Thomas >> >> >>>-----Ursprüngliche Nachricht----- >>>Von: Leandro Rodrigo Saad Cruz [mailto:le...@ib...] >>>Gesendet: Dienstag, 11. Juni 2002 15:47 >>>An: Mahler Thomas >>>Cc: 'Jakob Braeuchi'; ojb >>>Betreff: XML parser WAS[Re: AW: [OJB-developers] eliminating old junit >>>target] >>> >>> >>>Hi... which xml parser do you use ? I'm having problems with Entity >>>resolving ! >>> >>>-- >>>Leandro Rodrigo Saad Cruz >>>IT - Inter Business Tecnologia e Servicos (IB) >>>http://www.ibnetwork.com.br >>> >> |
|
From: Galvin H. <gk...@ya...> - 2002-06-11 17:32:41
|
Looking at the code, you are correct, it seems the prepared statements are cached and reused for: inserts deletions updates queries Given that Oracle 8i by default has only 50 open cursors, given a large amount of queries (reads) I was experiencing an ORA-01000. Although a DBA could probably come in and bump up the open cursor count for a particular DB instance, I think that the amount of open cursors might be reduced if the HashMap used a LRU scheme to discard prepared statements. I've looked at the statement code thoroughly and, correct me if I'm wrong, we re-use statements. We create a certain amount, and we store them in a statement hashmap. If you close the statement, a lot of tests will fail. Try it. I don't think oracle will eventually crap out, unless you have a HUGE amount of objects and thus statements. I question the value of caching statements as this is something the driver should probably do anyway. A future refactoring could accomplish this. The J2EE version uses cached sql strings instead of statements, and relies on the driver or app server to cache statements. m __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Matthew B. <ma...@so...> - 2002-06-11 15:19:09
|
Not a torque expert myself, but this is what I do:
In build.xml
<!-- load default profile (hsqldb) -->
<property file="profile/mssqldb.profile"/>
<!--<property file="profile/hsqldb.profile"/>-->
I comment/uncomment based on the profile I want to use. I'm sure this could
be externalized into the build.properties.
m
-----Original Message-----
From: Jakob Braeuchi [mailto:jbr...@ho...]
Sent: Monday, June 10, 2002 11:15 PM
To: Thomas Mahler; ojb
Subject: Re: [OJB-developers] eliminating old junit target
hi thomas,
does the new torque stuff also support switching of target db, like the old
build.properties did ?
jakob
|
|
From: Leandro R. S. C. <le...@ib...> - 2002-06-11 14:20:35
|
On Tue, 2002-06-11 at 11:04, Mahler Thomas wrote: > OJB ships with Crimson. > Crimson is a bit sloppy with validation etc. > I also tested release 0.9 with the latest Xerces distribution. Xerces 1 or 2 ? Xerces 2.0 is not working for me. 1.4.4 is ok. >=20 > cheers, >=20 > Thomas >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Leandro Rodrigo Saad Cruz [mailto:le...@ib...] > > Gesendet: Dienstag, 11. Juni 2002 15:47 > > An: Mahler Thomas > > Cc: 'Jakob Braeuchi'; ojb > > Betreff: XML parser WAS[Re: AW: [OJB-developers] eliminating old junit > > target] > >=20 > >=20 > > Hi... which xml parser do you use ? I'm having problems with Entity > > resolving ! > >=20 > > --=20 > > Leandro Rodrigo Saad Cruz > > IT - Inter Business Tecnologia e Servicos (IB) > > http://www.ibnetwork.com.br > >=20 --=20 Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Mahler T. <tho...@it...> - 2002-06-11 14:05:39
|
OJB ships with Crimson. Crimson is a bit sloppy with validation etc. I also tested release 0.9 with the latest Xerces distribution. cheers, Thomas > -----Urspr=FCngliche Nachricht----- > Von: Leandro Rodrigo Saad Cruz [mailto:le...@ib...] > Gesendet: Dienstag, 11. Juni 2002 15:47 > An: Mahler Thomas > Cc: 'Jakob Braeuchi'; ojb > Betreff: XML parser WAS[Re: AW: [OJB-developers] eliminating old = junit > target] >=20 >=20 > Hi... which xml parser do you use ? I'm having problems with Entity > resolving ! >=20 > --=20 > Leandro Rodrigo Saad Cruz > IT - Inter Business Tecnologia e Servicos (IB) > http://www.ibnetwork.com.br >=20 |
|
From: Leandro R. S. C. <le...@ib...> - 2002-06-11 13:46:00
|
Hi... which xml parser do you use ? I'm having problems with Entity resolving ! -- Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
|
From: Mahler T. <tho...@it...> - 2002-06-11 12:31:29
|
Hi again Joachim, > Hy, > > it's me again and I have another ODMG-Question (I hope > they'll get less, > when the ODMG-Book arrives). > > I'm now digging into the ODMG-Implementation and have some > question, first > I'd like to check, if my assertions are correct: > > When an object is registered with and ODMG-Transaction it > takes several > steps: > > - a Map is created that contains the content of each literal-field > (Strings, integers, Doubles, ...) of the object at the time > of the lock. correct > - each referenced (persistence-capable) object is registered > as well (with > the same time) correct > - each collection/array is walked through and each element is > handled the > same way a normal reference is handled (i.e. is registered). > correct > Now obviously this doesn't suffice to make newly added ojbects in the > collection persistent. Now my (maybe extremly naive) question is: Why > can't we handle Collections like literals. That is we create > a list of > objects that were contained in the list at lock-time and > compare this with > the real collection at commit-time to find out wether we need to > add/remove objects or not). As far as I see we don't need any > bytecode-enhancement here, or is there something obvious that I miss? > I think you are right. The original implementation is based on a simple recursion scheme that was very easy to implement. I guess your scheme could be implemented without major problems. But it will be a redesign of large parts of the existing ODMG lock and commit implementation. cheers, thomas > Now that I write it down, I even remember reading a > discussion about a > similar topic on the list some time ago. > > regards > Joachim Sauer > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: <Joa...@tp...> - 2002-06-11 12:00:10
|
Hy, it's me again and I have another ODMG-Question (I hope they'll get less, when the ODMG-Book arrives). I'm now digging into the ODMG-Implementation and have some question, first I'd like to check, if my assertions are correct: When an object is registered with and ODMG-Transaction it takes several steps: - a Map is created that contains the content of each literal-field (Strings, integers, Doubles, ...) of the object at the time of the lock. - each referenced (persistence-capable) object is registered as well (with the same time) - each collection/array is walked through and each element is handled the same way a normal reference is handled (i.e. is registered). Now obviously this doesn't suffice to make newly added ojbects in the collection persistent. Now my (maybe extremly naive) question is: Why can't we handle Collections like literals. That is we create a list of objects that were contained in the list at lock-time and compare this with the real collection at commit-time to find out wether we need to add/remove objects or not). As far as I see we don't need any bytecode-enhancement here, or is there something obvious that I miss? Now that I write it down, I even remember reading a discussion about a similar topic on the list some time ago. regards Joachim Sauer |
|
From: Mahler T. <tho...@it...> - 2002-06-11 07:56:22
|
Hi Matthew, > > #149 Poor performance of the "Inheritance on one table solution" > > I think this is solved with my refactoring, but maybe there > is something I'm > missing. Did this have to do with loading rows that didn't satisfy the > query, and having to reload rows that had different concrete class > attributes? > It was about loading rows that did not satisfy the query. As far as I can rememeber we did not yet think about the second problem! cheers, Thomas > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Mahler T. <tho...@it...> - 2002-06-11 06:47:22
|
Hi Jakob, > hi thomas, > > does the new torque stuff also support switching of target > db, like the old > build.properties did ? > I think it does. I think that's what the profiles (unser profile/) are meant for. But I don't know exactly how it can be triggered. I did not find a switch in build.properties or elsewhere. I hope the Torque experts can tell us :-) cheers, Thomas > jakob > > ----- Original Message ----- > From: "Thomas Mahler" <tho...@ho...> > To: "ojb" <obj...@li...> > Sent: Tuesday, June 11, 2002 7:00 AM > Subject: [OJB-developers] eliminating old junit target > > > > Hi all, > > > > I worked on build.xml to eliminate the old junit target and > related stuff. > > > > I kicked out the the old stuff and renamed junit2 to junit. > > I also removed the ojb.broker.util.ScriptTool. > > > > The file src/test/test/setup/db-setup.sql is now obsolete > and won't be > > referenced by any scripts. > > > > > > So we'll have to maintain only the Torque files to generate new > > test-tables and test-data. > > > > > > > > Thomas > > > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > > > _______________________________________________ > > Objectbridge-developers mailing list > > Obj...@li... > > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Jakob B. <jbr...@ho...> - 2002-06-11 06:15:01
|
hi thomas, does the new torque stuff also support switching of target db, like the old build.properties did ? jakob ----- Original Message ----- From: "Thomas Mahler" <tho...@ho...> To: "ojb" <obj...@li...> Sent: Tuesday, June 11, 2002 7:00 AM Subject: [OJB-developers] eliminating old junit target > Hi all, > > I worked on build.xml to eliminate the old junit target and related stuff. > > I kicked out the the old stuff and renamed junit2 to junit. > I also removed the ojb.broker.util.ScriptTool. > > The file src/test/test/setup/db-setup.sql is now obsolete and won't be > referenced by any scripts. > > > So we'll have to maintain only the Torque files to generate new > test-tables and test-data. > > > > Thomas > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > |
|
From: Thomas M. <tho...@ho...> - 2002-06-11 05:05:30
|
Hi Matthew, I patched build.xml, so that db-setup.sql is not longer used. So I just re-deleted it ! ant junit should now work without it! Thomas Matthew Baird wrote: > I had deleted my local copy to get a fresh one and it got committed as > deleted. > > Sorry for the inconvenience. > > m > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > |
|
From: Matthew B. <ma...@so...> - 2002-06-11 05:04:32
|
+1 for Thomas! -----Original Message----- From: Thomas Mahler [mailto:tho...@ho...] Sent: Monday, June 10, 2002 10:00 PM To: ojb Subject: [OJB-developers] eliminating old junit target Hi all, I worked on build.xml to eliminate the old junit target and related stuff. I kicked out the the old stuff and renamed junit2 to junit. I also removed the ojb.broker.util.ScriptTool. The file src/test/test/setup/db-setup.sql is now obsolete and won't be referenced by any scripts. So we'll have to maintain only the Torque files to generate new test-tables and test-data. Thomas _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Thomas M. <tho...@ho...> - 2002-06-11 05:00:27
|
Hi all, I worked on build.xml to eliminate the old junit target and related stuff. I kicked out the the old stuff and renamed junit2 to junit. I also removed the ojb.broker.util.ScriptTool. The file src/test/test/setup/db-setup.sql is now obsolete and won't be referenced by any scripts. So we'll have to maintain only the Torque files to generate new test-tables and test-data. Thomas |
|
From: Matthew B. <ma...@so...> - 2002-06-11 04:34:02
|
#149 Poor performance of the "Inheritance on one table solution" I think this is solved with my refactoring, but maybe there is something I'm missing. Did this have to do with loading rows that didn't satisfy the query, and having to reload rows that had different concrete class attributes? |
|
From: Matthew B. <ma...@so...> - 2002-06-11 04:26:39
|
I had deleted my local copy to get a fresh one and it got committed as deleted. Sorry for the inconvenience. m |
|
From: Matthew B. <ma...@so...> - 2002-06-11 04:21:51
|
I've looked at the statement code thoroughly and, correct me if I'm wrong,
we re-use statements. We create a certain amount, and we store them in a
statement hashmap. If you close the statement, a lot of tests will fail. Try
it.
I don't think oracle will eventually crap out, unless you have a HUGE amount
of objects and thus statements.
I question the value of caching statements as this is something the driver
should probably do anyway. A future refactoring could accomplish this.
The J2EE version uses cached sql strings instead of statements, and relies
on the driver or app server to cache statements.
m
-----Original Message-----
From: Galvin Hsiu [mailto:gk...@ya...]
Sent: Monday, June 10, 2002 11:13 AM
To: Matthew Baird; obj...@so...
Subject: RE: [OJB-developers] Fixes for ORA-01000 (open cursor problem)
Looking at the versioned history of RsIterator (circa
around 0.8.375 (prior to the BigCheckin - version 1.4)
the function releaseDbResources() is called when
cleaning up the RsIterator:
public void releaseDbResources()
{
try
{
Statement stmt = null;
if (m_rs != null)
{
stmt = m_rs.getStatement();
m_rs.close();
}
if (stmt != null)
{
stmt.close();
}
m_rs = null;
}
catch (Throwable t)
{
logger.error(t.getMessage());
// ignore problems during release
}
}
Here, the statement is explicitly closed. In the
version currently in cvs, function closeDbResources()
is simply a call to :
public void releaseDbResources()
{
m_broker.getStatementManager().closeResources(m_rsAndStmt.m_stmt,
m_rsAndStmt.m_rs);
}
And assuming that 0.8.375 is correct - in the
closeResources(), both the result set and statement
ARE closed.
The fix you propose will close the result set but
never close the statements, which will crap out sooner
or later and throw an ORA-01000. Unless there is a
point where the statement is explicitly closed, (I did
a grep for it and never came up with one within the
accesslayer), I think the ORA-01000 will still occur.
--- Matthew Baird <ma...@so...> wrote:
> Thanks for the input.
>
> Upon analysis, your patch is 1/2 correct. We can
> shut the resultset, but we
> have to keep the statement around as it is re-used.
> I put in the resultset
> closure code, and ran all tests and it works fine.
> Haven't tested it with
> Oracle, but it *should* solve the problem. Let me
> know if you find
> otherwise.
>
> Regards,
> Matthew
>
> -----Original Message-----
> From: Galvin Hsiu [mailto:gk...@ya...]
> Sent: Friday, June 07, 2002 2:24 PM
> To: obj...@li...
> Subject: [OJB-developers] Fixes for ORA-01000 (open
> cursor problem)
>
> In 0.9, I encountered an open cursor problem with
> Oracle, which is caused by prepared statements and
> results not getting closed properly (happened using
> the PersistentBrokerImpl in singleVM mode).
>
> The problem:
>
> Resultsets and PreparedStatements were not getting
> closed when issuing any kind of JdbcAccess calls.
>
> The cause of this is because there is nothing
> defined
> in StatementManager.closeResources()!
>
> Furthermore, the materializeObject is incorrect - in
> the older CVS version, it attempts to close just the
> resultset but not the prepared statement (this is
> for
> references and collections within the materialized
> object). The version in CVS attempts to close both,
> which would raise an exception.
>
> I unit tested this codefix while using SELECT * FROM
> V_$OPEN_CURSOR (internal user) - So far tests
> indicate
> everything is ok.
>
> In 0.8375 prior to this, this problem did not occur.
>
> The 2 fixes:
>
> 1) StatementManager.java
>
> public void closeResources(Statement stmt, ResultSet
> rs)
> {
> /* START NEW CODE */
>
> // if the resultset is valid, close it now
> try
> {
> if (rs != null)
> {
> rs.close();
> }
> }
> catch (SQLException ignored)
> {
> LoggerFactory.getDefaultLogger().warn("closing
> resultset had error: "+ ignored.getMessage());
> }
>
> // if the stmt is valid get the connection from
> it,
> // then close both
> if (stmt != null)
> {
> try
> {
> stmt.close();
> }
> catch (SQLException ignored)
> {
>
> LoggerFactory.getDefaultLogger().warn("closing
> statement had error: "+ ignored.getMessage());
> }
> }
> // now set them all to null
> rs = null;
> stmt = null;
>
> /* END NEW CODE */
> }
>
> 2) JdbcAccess.java
>
> public Object materializeObject(ClassDescriptor
> mif, Identity oid)
> throws PersistenceBrokerException
> {
> Object obj = null;
> ResultSet rs = null;
> PreparedStatement stmt = null;
> try
> {
> stmt =
>
broker.getStatementManager().getSelectByPKStatement(mif);
> synchronized (stmt)
> {
>
> broker.getStatementManager().bindSelect(stmt, oid);
> rs = stmt.executeQuery();
> // data available read object, else
> return null
> if (rs.next())
> {
> RowReader reader =
> mif.getRowReader();
> Object[] row = new
> Object[mif.getFieldDescriptions().length];
> reader.readObjectArrayFrom(rs,
> mif, row);
> obj =
> mif.getRowReader().readObjectFrom(row, mif);
> }
> else
> {
> obj = null;
> }
> }
> }
> catch (PersistenceBrokerException e)
> {
> logger.error("PersistenceBrokerException during
> the
> execution of materializeObject: " + e.getMessage(),
> e);
> throw e;
> }
> catch (SQLException e)
> {
> logger.error("SQLException during the execution
> of
> materializeObject: " + e.getMessage(), e);
> throw new
> PersistenceBrokerSQLException(e);
> }
> finally
> {
> /* START MODIFIED CODE */
> broker.getStatementManager().closeResources(null,
> rs);
> /* END MODIFIED CODE */
> }
>
> return obj;
> }
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
>
_______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application
> Developer's Conference
> August 25-28 in Las Vegas -
>
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
>
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: David W F. <dw...@la...> - 2002-06-11 04:04:34
|
Thanks for the correction., I have a hard time telling, since the output was cluttered with a traceback that was "normal". Dave Thomas Mahler writes: > Hi David, > > The failure you mention is in "testGetSomeC". > "ELVIS" is in "testBrokerCrash", which succeeds. > > cheers, > > Thomas > > David Forslund wrote: > > > But there is a failure reported in the junit2 test. There is a comment > > in the stack trace that: > > [junit] junit.framework.AssertionFailedError: count not right, found > > <49> should have got <39> This failure is expected if your driver > > doesn't support advanced JDBC operations. > > [junit] at junit.framework.Assert.fail(Assert.java:51) > > [junit] at > > test.ojb.odmg.ScrollableQueryResultsTest.testGetSomeC(ScrollableQueryResultsTest.java:334) > > > > .... > > followed by: > > [junit] Tests run: 114, Failures: 1, Errors: 0, Time elapsed: 14.37 sec > > [junit] TEST test.ojb.odmg.AllTests FAILED > > > > Dave > > > > Perhaps this is a fault with hsqldb? > > > > > > At 08:58 AM 6/10/2002 -0700, Matthew Baird wrote: > > > >> The ELVIS stacktrace is not an error, it's a test of crashing the > >> persistencebroker, so the stacktrace is expected. > >> > >> > >> > >> > >> > >> -----Original Message----- > >> *From:* David Forslund [mailto:dw...@la...] > >> *Sent:* Monday, June 10, 2002 8:42 AM > >> *To:* Matthew baird; tr...@th...; > >> obj...@li... > >> *Subject:* RE: [OJB-developers] Re: CVS build > >> > >> > >> > >> The beanutils are their, but the junit target still fails. Junit2 > >> almost works with a failure to find table ELVIS.in the running of > >> test.ojb.odmg.AllTests The test.ojb.broker.AllTests passed as did > >> test.ojb.sodal.AllTests > >> > >> Dave > >> At 11:18 PM 6/9/2002 -0700, Matthew baird wrote: > >> > >> > >> should be fixed now, do another checkout. > >> > > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: David F. <dw...@la...> - 2002-06-10 20:20:36
|
Yes. Our license is already essentially the same as the Apache license. I'm wondering if anyone is actually using this code. We are using it ourselves in our own packages. Thanks, Dave At 10:06 PM 6/10/2002 +0200, Thomas Mahler wrote: >Hi David, > >I'm currently checking if there are still pieces of code with incompatible >licenses. I found that there is some code in ojb.broker.query that >originates from OpenEMed. > >Namely classes: >DBException >SearchFilter >OJBSearchFilter > >Do you agree to place those files under the Apache licence? >If not, we will have to remove those classes from the OJB codebase. > >cheers, > >Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-06-10 20:07:00
|
Hi David, I'm currently checking if there are still pieces of code with incompatible licenses. I found that there is some code in ojb.broker.query that originates from OpenEMed. Namely classes: DBException SearchFilter OJBSearchFilter Do you agree to place those files under the Apache licence? If not, we will have to remove those classes from the OJB codebase. cheers, Thomas |
|
From: Galvin H. <gk...@ya...> - 2002-06-10 18:13:31
|
Looking at the versioned history of RsIterator (circa
around 0.8.375 (prior to the BigCheckin - version 1.4)
the function releaseDbResources() is called when
cleaning up the RsIterator:
public void releaseDbResources()
{
try
{
Statement stmt = null;
if (m_rs != null)
{
stmt = m_rs.getStatement();
m_rs.close();
}
if (stmt != null)
{
stmt.close();
}
m_rs = null;
}
catch (Throwable t)
{
logger.error(t.getMessage());
// ignore problems during release
}
}
Here, the statement is explicitly closed. In the
version currently in cvs, function closeDbResources()
is simply a call to :
public void releaseDbResources()
{
m_broker.getStatementManager().closeResources(m_rsAndStmt.m_stmt,
m_rsAndStmt.m_rs);
}
And assuming that 0.8.375 is correct - in the
closeResources(), both the result set and statement
ARE closed.
The fix you propose will close the result set but
never close the statements, which will crap out sooner
or later and throw an ORA-01000. Unless there is a
point where the statement is explicitly closed, (I did
a grep for it and never came up with one within the
accesslayer), I think the ORA-01000 will still occur.
--- Matthew Baird <ma...@so...> wrote:
> Thanks for the input.
>
> Upon analysis, your patch is 1/2 correct. We can
> shut the resultset, but we
> have to keep the statement around as it is re-used.
> I put in the resultset
> closure code, and ran all tests and it works fine.
> Haven't tested it with
> Oracle, but it *should* solve the problem. Let me
> know if you find
> otherwise.
>
> Regards,
> Matthew
>
> -----Original Message-----
> From: Galvin Hsiu [mailto:gk...@ya...]
> Sent: Friday, June 07, 2002 2:24 PM
> To: obj...@li...
> Subject: [OJB-developers] Fixes for ORA-01000 (open
> cursor problem)
>
> In 0.9, I encountered an open cursor problem with
> Oracle, which is caused by prepared statements and
> results not getting closed properly (happened using
> the PersistentBrokerImpl in singleVM mode).
>
> The problem:
>
> Resultsets and PreparedStatements were not getting
> closed when issuing any kind of JdbcAccess calls.
>
> The cause of this is because there is nothing
> defined
> in StatementManager.closeResources()!
>
> Furthermore, the materializeObject is incorrect - in
> the older CVS version, it attempts to close just the
> resultset but not the prepared statement (this is
> for
> references and collections within the materialized
> object). The version in CVS attempts to close both,
> which would raise an exception.
>
> I unit tested this codefix while using SELECT * FROM
> V_$OPEN_CURSOR (internal user) - So far tests
> indicate
> everything is ok.
>
> In 0.8375 prior to this, this problem did not occur.
>
> The 2 fixes:
>
> 1) StatementManager.java
>
> public void closeResources(Statement stmt, ResultSet
> rs)
> {
> /* START NEW CODE */
>
> // if the resultset is valid, close it now
> try
> {
> if (rs != null)
> {
> rs.close();
> }
> }
> catch (SQLException ignored)
> {
> LoggerFactory.getDefaultLogger().warn("closing
> resultset had error: "+ ignored.getMessage());
> }
>
> // if the stmt is valid get the connection from
> it,
> // then close both
> if (stmt != null)
> {
> try
> {
> stmt.close();
> }
> catch (SQLException ignored)
> {
>
> LoggerFactory.getDefaultLogger().warn("closing
> statement had error: "+ ignored.getMessage());
> }
> }
> // now set them all to null
> rs = null;
> stmt = null;
>
> /* END NEW CODE */
> }
>
> 2) JdbcAccess.java
>
> public Object materializeObject(ClassDescriptor
> mif, Identity oid)
> throws PersistenceBrokerException
> {
> Object obj = null;
> ResultSet rs = null;
> PreparedStatement stmt = null;
> try
> {
> stmt =
>
broker.getStatementManager().getSelectByPKStatement(mif);
> synchronized (stmt)
> {
>
> broker.getStatementManager().bindSelect(stmt, oid);
> rs = stmt.executeQuery();
> // data available read object, else
> return null
> if (rs.next())
> {
> RowReader reader =
> mif.getRowReader();
> Object[] row = new
> Object[mif.getFieldDescriptions().length];
> reader.readObjectArrayFrom(rs,
> mif, row);
> obj =
> mif.getRowReader().readObjectFrom(row, mif);
> }
> else
> {
> obj = null;
> }
> }
> }
> catch (PersistenceBrokerException e)
> {
> logger.error("PersistenceBrokerException during
> the
> execution of materializeObject: " + e.getMessage(),
> e);
> throw e;
> }
> catch (SQLException e)
> {
> logger.error("SQLException during the execution
> of
> materializeObject: " + e.getMessage(), e);
> throw new
> PersistenceBrokerSQLException(e);
> }
> finally
> {
> /* START MODIFIED CODE */
> broker.getStatementManager().closeResources(null,
> rs);
> /* END MODIFIED CODE */
> }
>
> return obj;
> }
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
>
>
_______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application
> Developer's Conference
> August 25-28 in Las Vegas -
>
http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
>
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
|
|
From: Matthew b. <mat...@ya...> - 2002-06-10 17:42:23
|
known to be a failure with HSQLDB. I'm going to make this test run conditionally based on driver support. I'll do that tonight.
David Forslund <dw...@la...> wrote: But there is a failure reported in the junit2 test. There is a comment in the stack trace that:
[junit] junit.framework.AssertionFailedError: count not right, found <49> should have got <39> This failure is expected if your driver doesn't support advanced JDBC operations.
[junit] at junit.framework.Assert.fail(Assert.java:51)
[junit] at test.ojb.odmg.ScrollableQueryResultsTest.testGetSomeC(ScrollableQueryResultsTest.java:334)
....
followed by:
[junit] Tests run: 114, Failures: 1, Errors: 0, Time elapsed: 14.37 sec
[junit] TEST test.ojb.odmg.AllTests FAILED
Dave
Perhaps this is a fault with hsqldb?
At 08:58 AM 6/10/2002 -0700, Matthew Baird wrote:
The ELVIS stacktrace is not an error, it's a test of crashing the persistencebroker, so the stacktrace is expected.
-----Original Message-----
From: David Forslund [mailto:dw...@la...]
Sent: Monday, June 10, 2002 8:42 AM
To: Matthew baird; tr...@th...; obj...@li...
Subject: RE: [OJB-developers] Re: CVS build
The beanutils are their, but the junit target still fails. Junit2 almost works with a failure to find table ELVIS.in the running of
test.ojb.odmg.AllTests The test.ojb.broker.AllTests passed as did test.ojb.sodal.AllTests
Dave
At 11:18 PM 6/9/2002 -0700, Matthew baird wrote:
should be fixed now, do another checkout.
---------------------------------
Do You Yahoo!?
Sign-up for Video Highlights of 2002 FIFA World Cup |
|
From: Thomas M. <tho...@ho...> - 2002-06-10 17:31:44
|
Hi David, The failure you mention is in "testGetSomeC". "ELVIS" is in "testBrokerCrash", which succeeds. cheers, Thomas David Forslund wrote: > But there is a failure reported in the junit2 test. There is a comment > in the stack trace that: > [junit] junit.framework.AssertionFailedError: count not right, found > <49> should have got <39> This failure is expected if your driver > doesn't support advanced JDBC operations. > [junit] at junit.framework.Assert.fail(Assert.java:51) > [junit] at > test.ojb.odmg.ScrollableQueryResultsTest.testGetSomeC(ScrollableQueryResultsTest.java:334) > > .... > followed by: > [junit] Tests run: 114, Failures: 1, Errors: 0, Time elapsed: 14.37 sec > [junit] TEST test.ojb.odmg.AllTests FAILED > > Dave > > Perhaps this is a fault with hsqldb? > > > At 08:58 AM 6/10/2002 -0700, Matthew Baird wrote: > >> The ELVIS stacktrace is not an error, it's a test of crashing the >> persistencebroker, so the stacktrace is expected. >> >> >> >> >> >> -----Original Message----- >> *From:* David Forslund [mailto:dw...@la...] >> *Sent:* Monday, June 10, 2002 8:42 AM >> *To:* Matthew baird; tr...@th...; >> obj...@li... >> *Subject:* RE: [OJB-developers] Re: CVS build >> >> >> >> The beanutils are their, but the junit target still fails. Junit2 >> almost works with a failure to find table ELVIS.in the running of >> test.ojb.odmg.AllTests The test.ojb.broker.AllTests passed as did >> test.ojb.sodal.AllTests >> >> Dave >> At 11:18 PM 6/9/2002 -0700, Matthew baird wrote: >> >> >> should be fixed now, do another checkout. >> > |
|
From: Jason v. Z. <jv...@ze...> - 2002-06-10 17:30:22
|
Hi, Only five people have sent in their contributor's agreements so far so here's another reminder :-) You can find the agreement here: http://www.apache.org/~jvanzyl/ASF_Contributor_License_1.txt I will attempt to move the code this weekend. I'm going to find out if I can do it even if everyone hasn't signed because there are always stragglers. I think I will plan to move the code over the weekend and whoever hasn't signed is just locked out until they have signed the agreement and send it in. -- jvz. Jason van Zyl jv...@ap... http://tambora.zenplex.org |
|
From: Thomas M. <tho...@ho...> - 2002-06-10 17:13:57
|
Hi Joachim, Joa...@tp... wrote: > Hy, > > I've got a question about ODMG. As I don't have the ODMG-Specification > (yet), I don't know wether the problem that I have is caused by my lack of > knowledge of how ODMG is supposed to work or if it is a real bug. > > I have an object of type SomeContainer that contains a List of other > objects (let's say, they are of type SomeStuff). Now I place a upgrad-lock > on the SomeContainer-Object, after I've aquired it from the Database. ODMG > goes around and places a lock on all objects referenced by the > SomeContainer object (directly and via collection). Just fine up to here. > Now I add an object to the list of SomeStuff-objects. When I call commit > now, should ODMG store the object and add a reference to the list or is it > the job of the programmer to explicitely lock the new object? > tricky question. If you were using an ODMG collection like DList instead of a normal Vector or ArrayList, OJB would behave as expected and store the new entry. The ODMG collections inform the current ODMG transaction about adding and removing of elements and do the locking for you. As far as I remember this is compliant to the ODMG spec. It is not required to provide tranparent persistence for any Collection class but only for the ODMG collections. It's sometimes difficult to decide how certain features should be implemented as the spec for the Java language binding is not always precise (The JDO spec is much cleaner). Even commercial OODBMS ODMG Java Bindings differ quite a lot ! Of course it would be better to let our ODMG implementation handle this automatically for all kind of collections! This would require some kind of byte-code enhancement. Maybe we can reuse parts of the JDO byte-code enhancer to implement this feature. > anyone can help? > > btw, does anyone know wether the ODMG-Standard is actually readable as a > reference or if it is typical ISO/ANSI/IEEE-standard-language (i.e. > totally useless for reference-purpose)? > The ODMG folks want you to buy their book. That's why the spec is not published on the WebSite. YOu can order the ODMG 3.0 book in any bookstore or directly at odmg.org: http://www.odmg.org/standard/orderingbook.html The book is really good and should be present in each OJB developers bookshelf ;-) cheers, Thomas > regards > Joachim Sauer > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
9 messages has been excluded from this view by a project administrator.
