objectbridge-developers Mailing List for ObJectRelationalBridge (Page 37)
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: Jakob B. <jbr...@ho...> - 2002-02-25 06:47:39
|
hi,
i've enhanced the oql-grammar to support is_defined, is_undefined and in:
querying for null can now be done in two ways (negative form in comment):
query.create("select persons from brj.ojb.Person where geburtsDatum = nil");
// <> nil
or:
query.create("select persons from brj.ojb.Person where
is_undefined(geburtsDatum)"); // is_defined(...)
for the in-query there arew also two flavours:
query.create("select persons from brj.ojb.Person where id in($1)");
query.bind(values); // values is a collection conatining
Integers
or:
query.create("select persons from brj.ojb.Person where id in(1,3,44)");
jakob
|
|
From: Florian B. <bf...@fl...> - 2002-02-23 15:54:51
|
Hi, > I just loaded your stuff from CVS and there is only one failure for the > delete TestCase. > The changes look quite straightforward. The failure within the delete testcase looks like it exposes another problem. If the foreign key ist part of the details primary key, the objects are retrieved correctly and the deletion works. If the foreign key is not part of the primary key the query doesn't return the correct objects. In the test case there are five different objects associated to a master object, but the query returns the same object five times, therefore there is still a fk constraint violation, because four objects remain related to the master object. lg, Florian, der trotz strahlendem Sonnenschein in Wien herumhackt... |
|
From: Thomas M. <tho...@ho...> - 2002-02-23 15:17:39
|
Hi Florian wrote: > > I think I have found a solution for this that is able to tell the order of > the added objects while maintaining the speed of the hashtable for lookups. > Only removing objects from the table would be more expensive. > great news! removing of objects is not an issue! >> > > So this is easy. TransactionImpl.register already resolves References and > Collections, just the order has to be changed. > Right! Sorry, I forgot to mention that register() can be used as a sample. > I just added the RI test case to CVS and I hope I can commit the fix today. > I just loaded your stuff from CVS and there is only one failure for the delete TestCase. The changes look quite straightforward. thanks, Thomas |
|
From: Florian B. <bf...@fl...> - 2002-02-23 12:27:15
|
Hi Thomas, <snip> > > Mmh. This is a good idea. But I think it is conflicting with the > hashtable concept. The hashtable is used to allow quick lookup of locked > objects during a tx. I think I have found a solution for this that is able to tell the order of the added objects while maintaining the speed of the hashtable for lookups. Only removing objects from the table would be more expensive. > > 2.) Change the order how dependent objects are > inserted/updated/deleted. > > Referenced objects are always the master, collections are always the > detail > > to an object. Currently I cannot think of a case where this could be > > different. > > > > This is exactly the depency graph I'm talking about! > By analysing the ReferenceDecsriptors and the CollectionDescriptors it > is possible to determine which object has to be inserted first etc. So this is easy. TransactionImpl.register already resolves References and Collections, just the order has to be changed. I just added the RI test case to CVS and I hope I can commit the fix today. <snip> best regards, Florian |
|
From: Thomas M. <tho...@ho...> - 2002-02-23 09:58:39
|
Hi Florian, <snip intro> > > Great, so I'll look further into the RI issue. What I think I could do is > the following: > > 1.) Maintain the order of write locks. This would make it possible for the > user to control this order and therefore resolve RI violations by inserting > objects in a proper order. Especially when OJB doesn't know about a RI this > would be good Mmh. This is a good idea. But I think it is conflicting with the hashtable concept. The hashtable is used to allow quick lookup of locked objects during a tx. > 2.) Change the order how dependent objects are inserted/updated/deleted. > Referenced objects are always the master, collections are always the detail > to an object. Currently I cannot think of a case where this could be > different. > This is exactly the depency graph I'm talking about! By analysing the ReferenceDecsriptors and the CollectionDescriptors it is possible to determine which object has to be inserted first etc. cu, Thomas > This would save us from calculating a sophisticated dependency graph I > think. > > best regards, > Florian > > > > > |
|
From: Florian B. <bf...@fl...> - 2002-02-22 21:10:05
|
> The ojb.odmg.TransactionImpl holds a ObjectEnvelopeTable that maintains a > Hashtable of all Objects locked to a Transaction. > > (The PersistenceBroker is not involved in these issues. I guess this was > a typo?) Well, not really a typo, just got things wrong ;-) > I will provide a fix for the second problem in the next release. > So you can concentrate on RI ;-) Great, so I'll look further into the RI issue. What I think I could do is the following: 1.) Maintain the order of write locks. This would make it possible for the user to control this order and therefore resolve RI violations by inserting objects in a proper order. Especially when OJB doesn't know about a RI this would be good 2.) Change the order how dependent objects are inserted/updated/deleted. Referenced objects are always the master, collections are always the detail to an object. Currently I cannot think of a case where this could be different. This would save us from calculating a sophisticated dependency graph I think. best regards, Florian |
|
From: Thomas M. <tho...@ho...> - 2002-02-22 20:22:48
|
Hi Florian
> Hi Thomas,
> >
> > The first bug is on the to do list for quite a long time (item 32).
> > The ODMG implementation just does not handle RI correctly right now!
>
> So this is really a bug and not something I am doing wrong.
> As I am digging
> further into the code I think I've found an explanation for
> the problem.
> PersistenceBroker maintains a Hashtable of objects to be
> inserted, updated
> in a transaction.
The ojb.odmg.TransactionImpl holds a ObjectEnvelopeTable that maintains a
Hashtable of all Objects locked to a Transaction.
(The PersistenceBroker is not involved in these issues. I guess this was
a typo?)
>Because the Hashtable returns the objects
> in random order
> there is no guarantee that the objects are inserted/updated
> in the same
> order as they are queued into PersistenceBroker. If we
> inserted/updated the
> objects in the correct order (i.e. the order that they were
> put into the
> queue) the problem could be solved. Then there needs to be
> just a minor
> modification so that references are stored in
> PersistenceBroker before the
> "root" object and collections afterwards.
>
> Does this make sense or is this a completely wrong approach.
>
You are on the right way!
The Objects in the table are stored without proper ordering with respect
to referential integrity dependencies.
The solution is simple: We have to compute a depency graph for all
objects locked to the tx. We can use the ClassDescriptor information to
compute this graph.
My idea (we already had some discussions regarding this issue) was to
have a comparator based on this depency graph. The comparator can be
used to sort the elements of the table before the broker is called to
store objects.
One important note: for insert we have to store master objects first and
detail objects later.
For deleting it's just inverse: first delete detail objects, then master
objects !
<snip>
> This at least avoids the exception. I now think that the
> problem has further
> consequences as it is in bindSelect(PreparedStatement, Identity). The
> relevant code looks as follows:
>
> public void bindSelect(PreparedStatement stmt, Identity
> oid) throws
> java.sql.SQLException
> {
> int i = 0;
> try
> {
> for (i = 0; i < oid.getPrimaryKeyValues().length; i++)
> {
> stmt.setObject(i + 1, oid.getPrimaryKeyValues()[i]);
> }
> [...]
>
> The problem is when oid.getPrimaryKeyValues()[i] returns
> null. In this case
> the Informix driver needs the JDBC-Type of the value to bind.
> The call would
> then be
> stmt.setObject(i+1, oid.getPrimaryKeyValues()[i], Types.XXX)
>
> In bindInsert for example the type of the parameter can be
> resolved, the
> call looks like:
> stmt.setObject(i+1, val, JdbcAccess.getSqlTypeAll(cld, i));
>
> If we had the type in bindSelect, the type could be passed to
> setObject, but
> we simply do not have this information here. I think we would
> be on the safe
> side if we always set the type of the object explicitly.
> Sometimes JDBC
> drivers do not know how to map an object to a SQL type and we
> could support
> it there.
>
The jdbc type info can be obtained from the respective ClassDescriptor by:
JdbcAccess.getSqlTypeAll(cld, i)
The ClassDescriptor cld could be obtained by:
ClassDescriptor cld = broker.getClassDescriptor(oid.getObjectsClass());
> > Of course this is a hack, but I have no idea how to avoid such
> > situations in a bulletproof way...
>
> I think this could be worth a try, but it either requires in
> depth knowledge
> of OJB internals or an architectural change in Identity, so I
> fear I cannot
> be of any help there.
>
Maybe the Referential Integrity problem is easier to start with, as it
does not require so much in depth OJB know how.
I will provide a fix for the second problem in the next release.
So you can concentrate on RI ;-)
> > hth,
> >
> > Thomas
> >
>
> best regards,
> Florian
>
> PS: Wofur steht eigentlich hth?
>
AFAIK HTH means: hope that helped!
(oder auf deutsch: hier werden Sie geholfen)
cu,
Thomas
|
|
From: Florian B. <bf...@fl...> - 2002-02-22 20:12:05
|
I just committed the following changes to CVS: - in build.xml added Informix and Oracle JDBC drivers to runtime classpath - in src/test/setup/db-setup.sql: Oracle does not know the type timestamp, equivalent type is DATE. - in src/test/setup/db-setup.sql: Informix does not know the type timestamp, equivalent type is DATETIME YEAR TO FRACTION - in src/test/setup/db-setup.sql: for table blob_test: Informix and Oracle both support the datatype BLOB and CLOB, therefore changed the datatype of the attributes to these types. - in src/test/setup/db-setup.sql: completed Informix JDBC driver information - in src/test/ojb/repository.xml: completed Informix driver information With these changes the JUnit test-suite should run "out of the box" for Informix and Oracle. best regards, Florian Bruckner |
|
From: Ranjan B. <ran...@fr...> - 2002-02-22 19:58:45
|
Eric, thanks -- Yes, the new version's working just fine (after I got 7.310 out of my classpath) Ranjan On Fri, 22 Feb 2002, Eric Bieschke wrote: > I was experiencing the same problem as you are until I started using OJB > version 0.7.343. If you're using OJB by putting jars on your classpath, > ensure that you've only got the specific jar you want to be using in your > classpath. Fyi, I'm using the ODMG interface against Oracle 8i, 8.1.6 using > the 'thin' oracle JDBC driver. > > - Eric > > ----- Original Message ----- > Subject: [OJB-developers] Open prepared statements > <snip> > > When the database got built to around 100 E2 entities I started > getting errors thatthe available cursors had been exhausted. > > Doing some investigation, I found that a prepared statement for > each E2 was being created, but they weren't being closed. I put a quick > patch into ojb.broker.accesslayer.JdbcAccess to cache prepared statements, > and close them when the RsIterator is cleaning up. > > This solves the immediate problem, but it isn't a long term fix. > > Has this been experienced before? Can I configure things differently so > I don't need the code change? > > <snip> > > |
|
From: Eric B. <EBi...@sa...> - 2002-02-22 19:52:50
|
I was experiencing the same problem as you are until I started using OJB version 0.7.343. If you're using OJB by putting jars on your classpath, ensure that you've only got the specific jar you want to be using in your classpath. Fyi, I'm using the ODMG interface against Oracle 8i, 8.1.6 using the 'thin' oracle JDBC driver. - Eric ----- Original Message ----- Subject: [OJB-developers] Open prepared statements <snip> When the database got built to around 100 E2 entities I started getting errors thatthe available cursors had been exhausted. Doing some investigation, I found that a prepared statement for each E2 was being created, but they weren't being closed. I put a quick patch into ojb.broker.accesslayer.JdbcAccess to cache prepared statements, and close them when the RsIterator is cleaning up. This solves the immediate problem, but it isn't a long term fix. Has this been experienced before? Can I configure things differently so I don't need the code change? <snip> |
|
From: Thomas M. <tho...@ho...> - 2002-02-22 18:07:54
|
Hi Ranjan, Ranjan Bagchi wrote: > Hi -- > > Since I'm new, I want to say that I'm quite impressed by > objectbridge: it's certainly easing a lot of the tedium of writing jdbc > applications. Congrats, really! > thanks ! <snip> > Doing some investigation, I found that a prepared statement for > each E2 was being created, but they weren't being closed. I put a quick > patch into ojb.broker.accesslayer.JdbcAccess to cache prepared statements, > and close them when the RsIterator is cleaning up. > > This solves the immediate problem, but it isn't a long term fix. > > Has this been experienced before? Yes, this is a known bug that is already fixed. Will be contained in the next release! Can I configure things differently so > I don't need the code change? > No, there is not much to configure here. OJB just must handle this correctly! HTH, Thomas |
|
From: Thomas M. <tho...@ho...> - 2002-02-22 18:07:51
|
Hi Ricardo, Ricardo Arg=FCello wrote: > Hello, >=20 > Nope, it didn't work. Mmh... >=20 > I'm still getting the same Exception when trying to get an object which= has a lot of relations with another objects. >=20 > This is the Exception (again): >=20 <snip> I will have a complete code walkthrough to fix this issue. For the time beeing you might consider disabling the use of proxies. Did you run the performance tests? Any results that could be interesting=20 for us? Imho, OJB won't perform bad (even without proxies) for a large range of=20 scenearios. cu, thomas |
|
From: <ri...@ya...> - 2002-02-22 16:03:38
|
Hello,
Nope, it didn't work.
I'm still getting the same Exception when trying to get an object which =
has a lot of relations with another objects.
This is the Exception (again):
[DEFAULT] WARN: problems with platform =
ojb.broker.platforms.PlatformMySQLImpl: o
jb.broker.platforms.PlatformMySQLImpl
[DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
<snip> .... (lots of these!)
[DEFAULT] WARN: problems with platform =
ojb.broker.platforms.PlatformMySQLImpl: o
jb.broker.platforms.PlatformMySQLImpl
[DEFAULT] WARN: OJB will use PlatformDefaultImpl instead
[DEFAULT] ERROR: Server configuration denies access to data source
java.sql.SQLException: Server configuration denies access to data source
at org.gjt.mm.mysql.MysqlIO.init(Unknown Source)
at org.gjt.mm.mysql.Connection.connectionInit(Unknown Source)
at org.gjt.mm.mysql.jdbc2.Connection.connectionInit(Unknown =
Source)
at org.gjt.mm.mysql.Driver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:517)
at java.sql.DriverManager.getConnection(DriverManager.java:177)
at =
ojb.broker.accesslayer.ConnectionFactoryDefaultImpl.newConnection(Con
nectionFactoryDefaultImpl.java:72)
at =
ojb.broker.accesslayer.ConnectionManager.getNewConnection(ConnectionM
anager.java:106)
at =
ojb.broker.accesslayer.ConnectionManager.getConnectionForClassDescrip
tor(ConnectionManager.java:93)
at =
ojb.broker.accesslayer.StatementsForClass.getConnection(StatementsFor
Class.java:134)
at =
ojb.broker.accesslayer.StatementsForClass.prepareStatement(Statements
ForClass.java:152)
at =
ojb.broker.accesslayer.StatementsForClass.getSelectByPKStmt(Statement
sForClass.java:370)
at =
ojb.broker.accesslayer.StatementManager.getSelectByPKStatement(Statem
entManager.java:439)
at =
ojb.broker.accesslayer.JdbcAccess.materializeObject(JdbcAccess.java:3
39)
at =
ojb.broker.singlevm.PersistenceBrokerImpl.getDBObject(PersistenceBrok
erImpl.java:1090)
at =
ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByIdentity(Persist
enceBrokerImpl.java:1208)
at =
ojb.broker.accesslayer.IndirectionHandler.materializeSubject(Indirect
ionHandler.java:216)
at =
ojb.broker.accesslayer.IndirectionHandler.getRealSubject(IndirectionH
andler.java:193)
at =
ojb.broker.accesslayer.IndirectionHandler.invoke(IndirectionHandler.j
ava:163)
at $Proxy0.getNombre(Unknown Source)
at =
charlie.util.JavascriptHelper.generateProyectosOptions(JavascriptHelp
er.java)
at org.apache.jsp.tarea$jsp._jspService(tarea$jsp.java:144)
at =
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspSer
vlet.java:202)
at =
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
82)
at =
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:679)
at =
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationD
ispatcher.java:431)
at =
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis
patcher.java:355)
at =
org.apache.struts.action.ActionServlet.processValidate(ActionServlet.
java:2149)
at =
org.apache.struts.action.ActionServlet.process(ActionServlet.java:156
5)
<snip>
Thanks in advance!
Ricardo
----- Original Message -----=20
From: "Mahler Thomas" <tho...@it...>
To: "'Ricardo Arg=FCello'" <ri...@ya...>; "Alex Cruise" =
<ac...@in...>; "Objectbridge (E-Mail)" =
<obj...@li...>
Sent: Thursday, February 21, 2002 4:40 AM
Subject: AW: [OJB-developers] ERROR: Server configuration denies access =
to data source
Hi Ricardo,
I had a look at the Proxy stuff. I believe that there is a bug in the =
Class
ojb.broker.accesslayer.IndirectionHandler.
Please replace the method materializeSubject with the following code:
private synchronized void materializeSubject() throws
PersistenceBrokerException
{
beforeMaterialization();
realSubject =3D getBroker().getObjectByIdentity(id);
// release broker after use !!!
PersistenceBrokerFactory.releaseInstance(broker);
if (realSubject =3D=3D null)
{
LoggerFactory.getDefaultLogger().warn("OJB broker could not
materialize " + id.toString());
}
afterMaterialization();
}
The Problem: With the new feature of a pool of brokers in the the
PersistenceBrokerFactory all obtained instances must be released after =
use!
The InvovationHandler just not did this.
Thus the PersistenceBrokerFactory generated tons of fresh broker =
instances
that all have their own JDBC connections.
Please tell me if this patch fixes you problem.
Thomas
> -----Urspr=FCngliche Nachricht-----
> Von: Ricardo Arg=FCello [mailto:ri...@ya...]
> Gesendet: Donnerstag, 21. Februar 2002 00:54
> An: Alex Cruise; Objectbridge (E-Mail)
> Betreff: Re: [OJB-developers] ERROR: Server configuration=20
> denies access
> to data source
>=20
>=20
>=20
> After I got this exception, I tried to login to the database=20
> using the "mysql" command line program, and it gave me this error:
>=20
> ERROR 1040: Too many connections
>=20
> Thant's why I'm sure it's a connection limit problem.
>=20
> Thanks!
>=20
> Ricardo
>=20
>=20
>=20
> ----- Original Message -----=20
> From: "Alex Cruise" <ac...@in...>
> To: "Objectbridge (E-Mail)"=20
> <obj...@li...>
> Sent: Wednesday, February 20, 2002 5:48 PM
> Subject: RE: [OJB-developers] ERROR: Server configuration=20
> denies access to data source
>=20
>=20
> From: Ricardo Arg=FCello [mailto:ri...@ya...]
>=20
> > It turns out that this error:
> > java.sql.SQLException: Server configuration denies access=20
> > to data source
> >=20
> > was caused because MySql used its "max_connections" limit of 100.
> >=20
> > I tried to initialize MySql with a parameter of=20
> > max_connections=3D1000, but it gave me the same error.
>=20
> Are you sure? I usually see this error when there's a=20
> permissions problem.
>=20
> -0xe1a
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
|
|
From: Ranjan B. <ran...@fr...> - 2002-02-22 14:11:58
|
Hi -- Since I'm new, I want to say that I'm quite impressed by objectbridge: it's certainly easing a lot of the tedium of writing jdbc applications. Congrats, really! So here's what I'm running into: I'm running against Oracle 8i, 8.1.6 My schema (and I'm trying to get it sufficiently reduced so I can share it) has an entity E with a collection attribute of entities E1 which further has a collection of entities E2. Pretty standard containment, with the repository set up so that loading E, loads up all the E1 and E2 attributes. Basically it's E +--<- E1 +--<- E2 When the database got built to around 100 E2 entities I started getting errors thatthe available cursors had been exhausted. Doing some investigation, I found that a prepared statement for each E2 was being created, but they weren't being closed. I put a quick patch into ojb.broker.accesslayer.JdbcAccess to cache prepared statements, and close them when the RsIterator is cleaning up. This solves the immediate problem, but it isn't a long term fix. Has this been experienced before? Can I configure things differently so I don't need the code change? Thanks! Ranjan Bagchi |
|
From: Florian B. <bf...@fl...> - 2002-02-21 22:29:53
|
Hi Thomas,
>
> The first bug is on the to do list for quite a long time (item 32).
> The ODMG implementation just does not handle RI correctly right now!
So this is really a bug and not something I am doing wrong. As I am digging
further into the code I think I've found an explanation for the problem.
PersistenceBroker maintains a Hashtable of objects to be inserted, updated
in a transaction. Because the Hashtable returns the objects in random order
there is no guarantee that the objects are inserted/updated in the same
order as they are queued into PersistenceBroker. If we inserted/updated the
objects in the correct order (i.e. the order that they were put into the
queue) the problem could be solved. Then there needs to be just a minor
modification so that references are stored in PersistenceBroker before the
"root" object and collections afterwards.
Does this make sense or is this a completely wrong approach.
> > As you can see, StatementManager wants to bind a parameter to a select
> > statement, unfortunately this parameter is null at that time,
> because it is
> > the foreign key to Master and this key is not set at that time.
> The reason
> > why the Informix JDBC driver crashes here is that it is unable
> to type the
> > null value correctly. If I set the type of the parameter in setObject
> > hardcoded to Types.INTEGER the setObject works and the
> behaviour is the same
> > as with the Oracle and the HSQLDB JDBC driver.
> >
>
>
> As you are using <autoincrement> you can use a cool OJB feature to force
> computation of the PK values of the Master table:
>
> Just say
> Master aMaster1 = new Master();
> Identity oid = new Identity(aMaster1);
>
> this will reflect the pk values of oid back into the aMaster1 object.
This at least avoids the exception. I now think that the problem has further
consequences as it is in bindSelect(PreparedStatement, Identity). The
relevant code looks as follows:
public void bindSelect(PreparedStatement stmt, Identity oid) throws
java.sql.SQLException
{
int i = 0;
try
{
for (i = 0; i < oid.getPrimaryKeyValues().length; i++)
{
stmt.setObject(i + 1, oid.getPrimaryKeyValues()[i]);
}
[...]
The problem is when oid.getPrimaryKeyValues()[i] returns null. In this case
the Informix driver needs the JDBC-Type of the value to bind. The call would
then be
stmt.setObject(i+1, oid.getPrimaryKeyValues()[i], Types.XXX)
In bindInsert for example the type of the parameter can be resolved, the
call looks like:
stmt.setObject(i+1, val, JdbcAccess.getSqlTypeAll(cld, i));
If we had the type in bindSelect, the type could be passed to setObject, but
we simply do not have this information here. I think we would be on the safe
side if we always set the type of the object explicitly. Sometimes JDBC
drivers do not know how to map an object to a SQL type and we could support
it there.
> Of course this is a hack, but I have no idea how to avoid such
> situations in a bulletproof way...
I think this could be worth a try, but it either requires in depth knowledge
of OJB internals or an architectural change in Identity, so I fear I cannot
be of any help there.
> hth,
>
> Thomas
>
best regards,
Florian
PS: Wofur steht eigentlich hth?
|
|
From: Thomas M. <tho...@ho...> - 2002-02-21 21:17:49
|
Hi Jason, Jason van Zyl wrote: >Hi, >I'm about to dig into OJB and I was wondering if any (Thomas, possibly) >can draw a short comparison between the design patterns of Scott Ambler >and OJB. This presentation could fill a book! I'll try to give you the management summary. I read Amblers papers before starting OJB. Sure! There are several things in OJB that can be found in his "The design of a robust persistence layer". Most prominent: The PersistenceBroker concept. I incorporated the Query API from the OpenSource project COBRA that applies Amblers PersistentCriteria concept. Reading Amblers paper on these topics is a must. But IMO these are the only aspects of Amblers presentation that maps directly to OJB. - Ambler concept relies on a persistent base class. - caching is not covered by his design - his concept of OID does not fit for legacy databases with compound PKs. - The OJB proxy concept is quite different (Ambler has proxy functionality in his PersistentObject base class.) - OJB does not provide Insert- and UpdateCriteria - OJB uses a different mapping approach (A full metadata layer) OJB is based on a variety of conceptual sources. 1. Craig Larmans "Applying UML & Patterns" (which again uses stuff from Ambler an others) 2. "Pattern-Oriented Software Architecture" 3. Scott Amblers Papers 4. The "Crossing Chasms" paper from Brown et. al. 5. GOF Design Patterns (sorted by relevance) The most important input came from "Applying UML and Patterns". It contains a chapter describing the design of a PersistenceBroker based approach persistence layer. His presentation contains a lot of other good ideas (e.g. usage of Proxies, caching etc.) I implemented a lot of his things 1:1. This book is a must have for all OJB developers [:-)] Larman does not cover the dynamic metadata concept. He mentiones that such a thing would be possible, but does not go into details. As I had been a fan of MetaLevel architectures for quite a while I wanted to have such a thing in OJB too !!! I took the concepts from the book Pattern-Oriented Software Architecture. They have a chapter on the Reflection pattern (aka Open Implementation, Meta-Level Architecture). They even provide an example how to apply this pattern to a persistence layer. This metadata layer make OJB so "unintrusive" as it allows to keep persistent objects totally free of persistence related methods. There is another Architectural pattern from this book that I am using: The Microkernel pattern. My idea was to have a kernel (the PersistenceBroker) that does all the hard work (O/R mapping, JDBC access, etc.) High Level object transaction frameworks like a ODMG or JDO implementations are clients to the PersistenceBroker kernel in this concept! There is one important concept in OJB that is not from a book: The Identity !!! In the early days of OJB I just used Object[] to represent an Objects primary keys. One day someone (I'm not sure but I believe it was David Dixon-Peugh) send me a mail, telling me: Hey you try to compute with Object identies. You must of course have a dedicated class for this concept ! For several detail questions (like mapping inheritance hierarchies) I consulted "crossing chasms". This is also a very good source for all O/R implementors. For all the "small things" I'm using the common GOF patterns like Factory, Observer, Singleton, Proxy, Adaptor, State, Command, (I even "invented" a unique mix of State- and command pattern in the ojb.odmg.states) etc. There is a very interesting document describing concepts very similar to OJB: http://www.lap.ttu.ee/erki/failid/konspekt/bakalaureusetoo/thesis.pdf. As I read this paper I saw a lot of thing "inspired" by OJB. It's giving a nice introduction into the PersistenceBroker pattern and related topics. I know this is only a very rough scetch, but I hope it helps to identify some of the sources behind the OJB design. If you have further questions, don't hesitate to ask! I think we need an in depth documentation on the OJB design. Frido started with a package level design documentation which maybe a good start (see an example in the JDOC for package ojb.broker.cache). cu, Thomas |
|
From: Florian B. <bf...@fl...> - 2002-02-21 16:32:42
|
Hi,
During some testing I discovered two problems, one for all databases and
another one specific to Informix.
I have a test case that exposes the more generic problem and I have a test
case that exposes the informix specific problem (Oracle and HSQLDB do not
show the specific problem). Both test cases share the same table and
repository definition.
The table definition is as follows:
e DROP TABLE MDTEST_DETAIL_FKNOPK;
e DROP TABLE MDTEST_DETAIL_FKINPK;
e DROP TABLE MDTEST_MASTER;
e CREATE TABLE MDTEST_MASTER (
MASTERID INT NOT NULL PRIMARY KEY,
MASTER_TEXT VARCHAR(255)
);
;
e CREATE TABLE MDTEST_DETAIL_FKINPK (
MASTERID INT NOT NULL,
DETAILID INT NOT NULL,
DETAIL_TEXT VARCHAR(255),
PRIMARY KEY (MASTERID, DETAILID),
FOREIGN KEY (MASTERID) REFERENCES MDTEST_MASTER(MASTERID)
);
;
e CREATE TABLE MDTEST_DETAIL_FKNOPK (
DETAILID INT NOT NULL PRIMARY KEY,
MASTERID INT NOT NULL,
DETAIL_TEXT VARCHAR(255),
FOREIGN KEY (MASTERID) REFERENCES MDTEST_MASTER(MASTERID)
);
MDTEST_MASTER is the master table for MDTEST_DETAIL_FKINPK and
MDTEST_DETAIL_FKNOPK. The detail tables differ in the way the primary key is
defined, in MDTEST_DETAIL_FKINPK the foreign key referencing to
MDTEST_MASTER is part of the primary key, in MDTEST_DETAIL_FKNOPK the
foreign key is just an attribute. MDTEST_DETAIL_FKNOPK exposes the generic
problem I have, MDTEST_DETAIL_FKINPK additionally exposes the informix
specific problem.
The repository definition for those tables is as follows:
<ClassDescriptor id="10000">
<class.name>test.ojb.odmgmd.Master</class.name>
<table.name>MDTEST_MASTER</table.name>
<FieldDescriptor id="1">
<field.name>masterId</field.name>
<column.name>MASTERID</column.name>
<jdbc_type>INTEGER</jdbc_type>
<PrimaryKey>true</PrimaryKey>
<autoincrement>true</autoincrement>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>masterText</field.name>
<column.name>MASTER_TEXT</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
<CollectionDescriptor id="1">
<cdfield.name>collDetailFKinPK</cdfield.name>
<items.class>test.ojb.odmgmd.DetailFKinPK</items.class>
<inverse_fk_descriptor_ids>1</inverse_fk_descriptor_ids>
</CollectionDescriptor>
<CollectionDescriptor id="2">
<cdfield.name>collDetailFKnoPK</cdfield.name>
<items.class>test.ojb.odmgmd.DetailFKinPK</items.class>
<inverse_fk_descriptor_ids>1</inverse_fk_descriptor_ids>
</CollectionDescriptor>
</ClassDescriptor>
<ClassDescriptor id="10001">
<class.name>test.ojb.odmgmd.DetailFKinPK</class.name>
<table.name>MDTEST_DETAIL_FKINPK</table.name>
<FieldDescriptor id="1">
<field.name>masterId</field.name>
<column.name>MASTERID</column.name>
<jdbc_type>INTEGER</jdbc_type>
<PrimaryKey>true</PrimaryKey>
</FieldDescriptor>
<FieldDescriptor id="2">
<field.name>detailId</field.name>
<column.name>DETAILID</column.name>
<jdbc_type>INTEGER</jdbc_type>
<PrimaryKey>true</PrimaryKey>
<autoincrement>true</autoincrement>
</FieldDescriptor>
<FieldDescriptor id="3">
<field.name>detailText</field.name>
<column.name>DETAIL_TEXT</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
<ReferenceDescriptor id="1">
<rdfield.name>aMaster</rdfield.name>
<referenced.class>test.ojb.odmgmd.Master</referenced.class>
<fk_descriptor_ids>1</fk_descriptor_ids>
</ReferenceDescriptor>
</ClassDescriptor>
<ClassDescriptor id="10002">
<class.name>test.ojb.odmgmd.DetailFKnoPK</class.name>
<table.name>MDTEST_DETAIL_FKNOPK</table.name>
<FieldDescriptor id="2">
<field.name>detailId</field.name>
<column.name>DETAILID</column.name>
<jdbc_type>INTEGER</jdbc_type>
<PrimaryKey>true</PrimaryKey>
<autoincrement>true</autoincrement>
</FieldDescriptor>
<FieldDescriptor id="1">
<field.name>masterId</field.name>
<column.name>MASTERID</column.name>
<jdbc_type>INTEGER</jdbc_type>
</FieldDescriptor>
<FieldDescriptor id="3">
<field.name>detailText</field.name>
<column.name>DETAIL_TEXT</column.name>
<jdbc_type>VARCHAR</jdbc_type>
</FieldDescriptor>
<ReferenceDescriptor id="1">
<rdfield.name>aMaster</rdfield.name>
<referenced.class>test.ojb.odmgmd.Master</referenced.class>
<fk_descriptor_ids>1</fk_descriptor_ids>
</ReferenceDescriptor>
</ClassDescriptor>
The following code shows the problem. The behaviour I expected is that first
the master objects are made persistent and then the detail objects.
tx.begin();
Master aMaster1 = new Master();
aMaster1.masterText = "Master 1";
aMaster1.collDetailFKnoPK = new java.util.Vector();
for (int i = 0; i < 5; i++)
{
DetailFKnoPK aDetail = new DetailFKnoPK();
aDetail.detailText = "Artikel " + i + " in Produktgruppe 1";
aDetail.aMaster = aMaster1;
aMaster1.collDetailFKnoPK.add(aDetail);
}
Master aMaster2 = new Master();
aMaster2.masterText = "Master 2";
aMaster2.collDetailFKnoPK = new java.util.Vector();
for (int i = 0; i < 5; i++)
{
DetailFKnoPK aDetail = new DetailFKnoPK();
aDetail.detailText = "Artikel " + i + " in Produktgruppe 1";
aDetail.aMaster = aMaster2;
aMaster2.collDetailFKnoPK.add(aDetail);
}
db.makePersistent(aMaster1);
db.makePersistent(aMaster2);
tx.commit();
The problem is, OJB tries to make the detail persistent before the master is
persistent, resulting in a foreign key constraint violation. The output is
as follows (for Informix, very similar for HSQLDB):
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity
ojb.broker.util.HighLowSequence{test.ojb.odmgmd.Master,masterId}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@11d8c1
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@11d8c1, true
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.Master{1}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity
ojb.broker.util.HighLowSequence{test.ojb.odmgmd.DetailFKnoPK,detailId}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@6df84b
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@6df84b, true
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{1}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{2}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{3}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{4}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{5}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.Master{2}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{6}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{7}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{8}
[junit] org.odmg.TransactionAbortedException: Missing key in referenced
table for referential constraint (informix.r696_1460).
[junit] at
ojb.odmg.ObjectEnvelopeTable.commit(ObjectEnvelopeTable.java:86)
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{9}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKnoPK{10}
[junit] at ojb.odmg.TransactionImpl.doCommit(TransactionImpl.java:196)
[junit] at ojb.odmg.TransactionImpl.commit(TransactionImpl.java:347)
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
test.ojb.odmgmd.DetailFKnoPK@246701, true
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKnoPK(OdmgTestCollecti
onsAndReferences.java:92)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] F
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] Time: 2,483
[junit] There was 1 failure:
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
[junit] 1)
testFKnoPK(test.ojb.odmgmd.OdmgTestCollectionsAndReferences)junit.framework.
AssertionFailedError: testFKnoPK: Missing key in referenced table for
referential constraint (informix.r696_1460).
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKnoPK(OdmgTestCollecti
onsAndReferences.java:97)
Now the second testcase. I have to say that I modified the Exception
handling of OJB a little bit on the path to the source of the problem, so
whenever a new exception is thrown as a result of another exception, the
stacktrace is printed. The source is similar to testcase 1, the only
difference is that the detail class is now DetailFKinPK. The result is the
following:
[junit] .[BOOT] INFO: OJB.properties:
file:/C:/work/OJB/ojb-0.7.343-src/ojb-0.7.343/build/test/ojb/OJB.properties
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity
ojb.broker.util.HighLowSequence{test.ojb.odmgmd.Master,masterId}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@11d8c1
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@11d8c1, true
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.Master{1}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity
ojb.broker.util.HighLowSequence{test.ojb.odmgmd.DetailFKinPK,detailId}
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@6df84b
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO: store
ojb.broker.util.HighLowSequence@6df84b, true
[junit] [ojb.broker.singlevm.PersistenceBrokerImpl] INFO:
getObjectByIdentity test.ojb.odmgmd.DetailFKinPK{null,1}
[junit] [DEFAULT] ERROR: bindSelect failed for:
test.ojb.odmgmd.DetailFKinPK{null,1}, PK: 0, value: null
[junit] java.sql.SQLException: System or internal error
java.lang.NullPointerException
[junit] at
com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:423)
[junit] at
com.informix.jdbc.IfxPreparedStatement.setObject(IfxPreparedStatement.java:2
243)
[junit] at
ojb.broker.accesslayer.StatementManager.bindSelect(StatementManager.java:317
)
[junit] at
ojb.broker.accesslayer.JdbcAccess.materializeObject(JdbcAccess.java:342)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.
java:1090)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBro
kerImpl.java:1208)
[junit] at
ojb.odmg.ObjectEnvelope.setInitialModificationState(ObjectEnvelope.java:247)
[junit] at ojb.odmg.ObjectEnvelope.<init>(ObjectEnvelope.java:74)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:481)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at
ojb.odmg.TransactionImpl.lockCollections(TransactionImpl.java:535)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:495)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at ojb.odmg.DatabaseImpl.makePersistent(DatabaseImpl.java:220)
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKinPK(OdmgTestCollecti
onsAndReferences.java:134)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
[junit] System or internal error java.lang.NullPointerException
[junit] at
ojb.broker.accesslayer.JdbcAccess.materializeObject(JdbcAccess.java:369)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.
java:1090)
[junit] at
ojb.broker.singlevm.PersistenceBrokerImpl.getObjectByIdentity(PersistenceBro
kerImpl.java:1208)
[junit] at
ojb.odmg.ObjectEnvelope.setInitialModificationState(ObjectEnvelope.java:247)
[junit] at ojb.odmg.ObjectEnvelope.<init>(ObjectEnvelope.java:74)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:481)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at
ojb.odmg.TransactionImpl.lockCollections(TransactionImpl.java:535)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:495)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at ojb.odmg.DatabaseImpl.makePersistent(DatabaseImpl.java:220)
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKinPK(OdmgTestCollecti
onsAndReferences.java:134)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
[junit] org.odmg.ODMGRuntimeException: System or internal error
java.lang.NullPointerException
[junit] at
ojb.odmg.ObjectEnvelope.setInitialModificationState(ObjectEnvelope.java:252)
[junit] at ojb.odmg.ObjectEnvelope.<init>(ObjectEnvelope.java:74)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:481)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at
ojb.odmg.TransactionImpl.lockCollections(TransactionImpl.java:535)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:495)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at ojb.odmg.DatabaseImpl.makePersistent(DatabaseImpl.java:220)
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKinPK(OdmgTestCollecti
onsAndReferences.java:134)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
[junit] org.odmg.LockNotGrantedException: System or internal error
java.lang.NullPointerException
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:167)
[junit] at
ojb.odmg.TransactionImpl.lockCollections(TransactionImpl.java:535)
[junit] at ojb.odmg.TransactionImpl.register(TransactionImpl.java:495)
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:162)
[junit] at ojb.odmg.DatabaseImpl.makePersistent(DatabaseImpl.java:220)
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKinPK(OdmgTestCollecti
onsAndReferences.java:134)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
[junit] org.odmg.LockNotGrantedException: System or internal error
java.lang.NullPointerException
[junit] at ojb.odmg.TransactionImpl.lock(TransactionImpl.java:167)
[junit] at ojb.odmg.DatabaseImpl.makePersistent(DatabaseImpl.java:220)
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKinPK(OdmgTestCollecti
onsAndReferences.java:134)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
[junit] org.odmg.ODMGRuntimeException
[junit] at ojb.odmg.DatabaseImpl.makePersistent(DatabaseImpl.java:229)
[junit] at
test.ojb.odmgmd.OdmgTestCollectionsAndReferences.testFKinPK(OdmgTestCollecti
onsAndReferences.java:134)
[junit] at java.lang.reflect.Method.invoke(Native Method)
[junit] at junit.framework.TestCase.runTest(TestCase.java:166)
[junit] at junit.framework.TestCase.runBare(TestCase.java:140)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:131)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:173)
[junit] at junit.framework.TestSuite.run(TestSuite.java:168)
[junit] at junit.textui.TestRunner.doRun(TestRunner.java:74)
[junit] F
[junit] at junit.textui.TestRunner.start(TestRunner.java:234)
[junit] at junit.textui.TestRunner.main(TestRunner.java:112)
As you can see, StatementManager wants to bind a parameter to a select
statement, unfortunately this parameter is null at that time, because it is
the foreign key to Master and this key is not set at that time. The reason
why the Informix JDBC driver crashes here is that it is unable to type the
null value correctly. If I set the type of the parameter in setObject
hardcoded to Types.INTEGER the setObject works and the behaviour is the same
as with the Oracle and the HSQLDB JDBC driver.
I am quite lost with these two problems as this seems to touch the internals
of OJB.
Attached is the complete JUnit test case so you can see the problems.
best regards,
Florian
|
|
From: Darren S. <Dar...@cw...> - 2002-02-21 15:22:27
|
We've had a few problems with the Criteria class - specifically addEqualTo and
addNotEqualTo methods which allow wildcard processing. Since we wanted the
ability to search for '*' characters we needed some kind of escape mechanism for
these chars.
I'm not sure this is required given the direction of soda but please find
attached some sample code for Criteria which allows escaping - using the '\'
character.
I also noticed some comments regarding wildcard processing for addEqualToColumn
- however the method doesn't appear to implement any wildcard processing - I've
left this for the time being...
Regards
Darren
(See attached file: Criteria.java)
******************************************************************************************************************************************************
This e-mail has been prepared using information believed by the author to be
reliable and accurate, but Thales Information Systems Finance makes no
warranty as to accuracy or completeness. In particular Thales Information
Systems Finance does not accept responsibility for changes made to this
e-mail after it was sent. Any opinions expressed in this document are those of
the author and do not necessarily reflect the opinions of the company or its
affiliates. They may be subject to change without notice.
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and may be legally privileged and/or
confidential. Access by any other party is unauthorised without the express
written permission of the sender. If you have received this e-mail in error you
may not copy or use the contents, attachments or information in any way.
Please destroy it and contact the sender via the Thales Information Systems
Finance switchboard in London at +44 (0) 20 7650 0100 or via e-mail return.
This message and any attachments have been scanned
for viruses prior to leaving the originators network. The originator does not
guarantee the security of this message and will not be responsible for any
damages arising from any alteration of this message by a third party or as a
result of any virus being passed on.
*******************************************************************************************************************************************************
(UUEncoded file named: Criteria.java follows)
begin 644 Criteria.java
M+RH-"B`J("1)9#H@0W)I=&5R:6$N:F%V82QV(#$N,R`R,#`R+S`Q+S(S(#(Q
M.C0P.C0S('1O;2!%>'`@)`T*("H@0T]"4D$@+2!*879A($]B:F5C="!097)S
M:7-T96YC92!,87EE<@T*("H@0V]P>7)I9VAT("A#*2`Q.3DW+"`Q.3DX("`@
M($1"($AA<G9E>2U'96]R9V4-"B`J(&5-86EL.B!C;V)R84!L;W=R96YT+F]R
M9PT*("H-"B`J#0H@*B!4:&ES('!R;V=R86T@:7,@9G)E92!S;V9T=V%R93L@
M>6]U(&-A;B!R961I<W1R:6)U=&4@:70@86YD+V]R#0H@*B!M;V1I9GD@:70@
M=6YD97(@=&AE('1E<FUS(&]F('1H92!'3E4@1V5N97)A;"!0=6)L:6,@3&EC
M96YS90T*("H@87,@<'5B;&ES:&5D(&)Y('1H92!&<F5E(%-O9G1W87)E($9O
M=6YD871I;VX[(&5I=&AE<B!V97)S:6]N(#(-"B`J(&]F('1H92!,:6-E;G-E
M+"!O<B`H870@>6]U<B!O<'1I;VXI(&%N>2!L871E<B!V97)S:6]N+@T*("H-
M"B`J(%1H:7,@<')O9W)A;2!I<R!D:7-T<FEB=71E9"!I;B!T:&4@:&]P92!T
M:&%T(&ET('=I;&P@8F4@=7-E9G5L+`T*("H@8G5T(%=)5$A/550@04Y9(%=!
M4E)!3E19.R!W:71H;W5T(&5V96X@=&AE(&EM<&QI960@=V%R<F%N='D@;V8-
M"B`J($U%4D-(04Y404))3$E462!O<B!&251.15-3($9/4B!!(%!!4E1)0U5,
M05(@4%524$]312X@(%-E92!T:&4-"B`J($=.52!'96YE<F%L(%!U8FQI8R!,
M:6-E;G-E(&9O<B!M;W)E(&1E=&%I;',N#0H@*@T*("H@66]U('-H;W5L9"!H
M879E(')E8V5I=F5D(&$@8V]P>2!O9B!T:&4@1TY5($=E;F5R86P@4'5B;&EC
M($QI8V5N<V4-"B`J(&%L;VYG('=I=&@@=&AI<R!P<F]G<F%M.R!I9B!N;W0L
M('=R:71E('1O('1H92!&<F5E(%-O9G1W87)E#0H@*B!&;W5N9&%T:6]N+"!)
M;F,N+"`U.2!496UP;&4@4&QA8V4@+2!3=6ET92`S,S`L($)O<W1O;BP@34$@
M(#`R,3$Q+3$S,#<L(%5302X-"B`J+PT*<&%C:V%G92!O:F(N8G)O:V5R+G%U
M97)Y.PT*#0II;7!O<G0@;VIB+F)R;VME<BYA8V-E<W-L87EE<BY3<6Q'96YE
M<F%T;W([#0H-"FEM<&]R="!J879A+G5T:6PN0V]L;&5C=&EO;CL-"FEM<&]R
M="!J879A+G5T:6PN16YU;65R871I;VX[#0II;7!O<G0@:F%V82YU=&EL+E9E
M8W1O<CL-"@T*+RHJ#0H@*B!097)S:7-T96YT($-R:71E<FEA(&-A;B!B92!U
M<V5D('1O(')E=')I979E('-E=',@;V8@;V)J96-T<R!B87-E9"!O;B!T:&5I
M<B!A='1R:6)U=&5S#0H@*B!.;W)M86QL>2!E86-H(&%T=')I8G5T92!I<R!!
M3D1E9"!T;V=E=&AE<BP@86X@3U(@8V%N(&)E('!E<F9O<FUE9"!B>2!C<F5A
M=&EN9R!A(&YE=PT*("H@4&5R<VES=&5N=$-R:71E<FEA(&%N9"!A9&1I;F<@
M:70N#0H@*B`\4#X-"B`J($-R:71E<FEA(&%R92!U<V5D+"!R871H97(@=&AA
M;B!A('-I;7!L92!S=')I;F<L(&)E8V%U<V4@=&AE>2!C86X@8F4@<')E8V]M
M<&EL960@9F]R#0H@*B!E9F9I8VEE;F-Y+@T*("HO#0IP=6)L:6,@8VQA<W,@
M0W)I=&5R:6$@:6UP;&5M96YT<R!J879A+FEO+E-E<FEA;&EZ86)L90T*>PT*
M("`@('!U8FQI8R!F:6YA;"!S=&%T:6,@:6YT($]2(#T@,#L-"B`@("!P=6)L
M:6,@9FEN86P@<W1A=&EC(&EN="!!3D0@/2`Q.PT*("`@('!U8FQI8R!F:6YA
M;"!S=&%T:6,@:6YT($Y/3D4@/2`Y.PT*("`@('!R:79A=&4@5F5C=&]R(&-R
M:71E<FEA.PT*("`@('!R:79A=&4@:6YT('1Y<&4[#0H@("`@<')I=F%T92!B
M;V]L96%N(&5M8G)A8V5D.PT*#0H@("`@<')I=F%T92!3=')I;F<@;W)D97)B
M>2`](&YU;&P[#0H@("`@<')I=F%T92!B;V]L96%N(&%S8V5N9&EN9R`]('1R
M=64[#0H-"B`@("`O*BH-"B`@("`@*B!#;VYS=')U8W1O<B!D96-L87)A=&EO
M;@T*("`@("`J#0H@("`@("H-"B`@("`@*@T*("`@("`J+PT*("`@('!U8FQI
M8R!#<FET97)I82@I#0H@("`@>PT*("`@("`@("!C<FET97)I82`](&YE=R!6
M96-T;W(H*3L-"B`@("`@("`@='EP92`]($Y/3D4[#0H@("`@("`@(&5M8G)A
M8V5D(#T@9F%L<V4[#0H@("`@?0T*#0H@("`@+RHJ#0H@("`@("H@365T:&]D
M(&1E8VQA<F%T:6]N#0H@("`@("H-"B`@("`@*@T*("`@("`J($!R971U<FX-
M"B`@("`@*@T*("`@("`J#0H@("`@("HO#0H@("`@<'5B;&EC($5N=6UE<F%T
M:6]N(&=E=$5L96UE;G1S*"D-"B`@("![#0H@("`@("`@(')E='5R;B!C<FET
M97)I82YE;&5M96YT<R@I.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J($UE
M=&AO9"!D96-L87)A=&EO;@T*("`@("`J#0H@("`@("H-"B`@("`@*B!`<F5T
M=7)N#0H@("`@("H-"B`@("`@*@T*("`@("`J+PT*("`@('!R;W1E8W1E9"!6
M96-T;W(@9V5T0W)I=&5R:6$H*0T*("`@('L-"B`@("`@("`@<F5T=7)N(&-R
M:71E<FEA.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J($UE=&AO9"!D96-L
M87)A=&EO;@T*("`@("`J#0H@("`@("H-"B`@("`@*B!`<F5T=7)N#0H@("`@
M("H-"B`@("`@*@T*("`@("`J+PT*("`@('!U8FQI8R!I;G0@9V5T5'EP92@I
M#0H@("`@>PT*("`@("`@("!R971U<FX@='EP93L-"B`@("!]#0H-"B`@("`O
M*BH-"B`@("`@*B!-971H;V0@9&5C;&%R871I;VX-"B`@("`@*@T*("`@("`J
M#0H@("`@("H@0'!A<F%M('1Y<&4-"B`@("`@*@T*("`@("`J#0H@("`@("HO
M#0H@("`@<'5B;&EC('9O:60@<V5T5'EP92AI;G0@='EP92D-"B`@("![#0H@
M("`@("`@('1H:7,N='EP92`]('1Y<&4[#0H@("`@?0T*#0H@("`@+RHJ#0H@
M("`@("H@365T:&]D(&1E8VQA<F%T:6]N#0H@("`@("H-"B`@("`@*@T*("`@
M("`J($!R971U<FX-"B`@("`@*@T*("`@("`J#0H@("`@("HO#0H@("`@<'5B
M;&EC(&)O;VQE86X@:7-%;6)R86-E9"@I#0H@("`@>PT*("`@("`@("!R971U
M<FX@96UB<F%C960[#0H@("`@?0T*#0H@("`@+RHJ#0H@("`@("H@365T:&]D
M(&1E8VQA<F%T:6]N#0H@("`@("H-"B`@("`@*@T*("`@("`J($!P87)A;2!E
M;6)R86-E9`T*("`@("`J#0H@("`@("H-"B`@("`@*B\-"B`@("!P=6)L:6,@
M=F]I9"!S971%;6)R86-E9"AB;V]L96%N(&5M8G)A8V5D*0T*("`@('L-"B`@
M("`@("`@=&AI<RYE;6)R86-E9"`](&5M8G)A8V5D.PT*("`@('T-"@T*("`@
M("\J*@T*("`@("`J($%D9',@86YD(&5Q=6%L<R`H/2D@8W)I=&5R:6$L#0H@
M("`@("H@8W5S=&]M97)?:60@/2`Q,#`S-`T*("`@("`J(#Q0/@T*("`@("`J
M(%=H97)E(%9A;'5E(&ES(&$@<W1R:6YG('-I;7!L92!P871T97)N(&UA=&-H
M:6YG(&-A;B!B92!U<V5D+"!T:&4-"B`@("`@*B!C:&%R86-T97(@*B!I<R!A
M('=I;&1C87)D+"!E+F<N#0H@("`@("H@8W5S=&]M97)?;F%M92`]($%N9&5R
M*@T*("`@("`J(#Q0/@T*("`@("`J(%=O=6QD(&UA=&-H('1H92!C=7-T;VUE
M<G,Z($%N9&5R<V]N(&%N9"!!;F1E<G1O;BX@(%1H92!C:&%R86-T97(@/R!M
M871C:&5S(&$@<VEN9VQE#0H@("`@("H@;V-C=7)E;F-E(&]F(&$@8VAA<F%C
M=&5R+@T*("`@("`J#0H@("`@("H@5&AE("=<)R!C:&%R86-T97(@:7,@=7-E
M9"!A<R!A;B!E<V-A<&4@8VAA<F%C=&5R(&%N9"!A;&QO=R!S96%R8VAI;F<@
M9F]R('-T<FEN9W,-"B`@("`@*B!C;VYT86EN:6YG("H@;W(@/RX@(%-O(&EN
M(&]R9&5R('1O('-E87)C:"!F;W(@06YD97(J("T@=7-E($%N9&5R7"HN#0H@
M("`@("H-"B`@("`@*B!`<&%R86T@(&%T=')I8G5T92`@(%1H92!F:65L9"!N
M86UE('1O(&)E('5S960-"B`@("`@*B!`<&%R86T@('9A;'5E("`@("`@($%N
M(&]B:F5C="!R97!R97-E;G1I;F<@=&AE('9A;'5E(&]F('1H92!F:65L9`T*
M("`@("`J+PT*("`@('!U8FQI8R!V;VED(&%D9$5Q=6%L5&\H4W1R:6YG(&%T
M=')I8G5T92P@3V)J96-T('9A;'5E*0T*("`@('L-"B`@("`@("`@:68@*'9A
M;'5E(&EN<W1A;F-E;V8@4W1R:6YG*0T*("`@("`@("![#0H@("`@("`@("`@
M("`O+R!S=6)S=&ET=71E(&]U<B!S<&5C:6%L(&-H87)A8W1E<B!F;W(@4U%,
M('9E<G-I;VYS#0H@("`@("`@("`@("!3=')I;F<@<&%T=&5R;B`](&=E;F5R
M871E4U%,4V5A<F-H4&%T=&5R;B@H4W1R:6YG*79A;'5E*3L-"B`@("`@("`@
M("`@(&EF("@H<&%T=&5R;BYI;F1E>$]F*"<E)RD@/3T@+3$I("8F("AP871T
M97)N+FEN9&5X3V8H)U\G*2`]/2`M,2DI#0H@("`@("`@("`@("`@("`@8W)I
M=&5R:6$N861D16QE;65N="AN97<@17%U86Q4;T-R:71E<FEA*&%T=')I8G5T
M92P@<&%T=&5R;BDI.PT*("`@("`@("`@("`@96QS90T*("`@("`@("`@("`@
M("`@(&-R:71E<FEA+F%D9$5L96UE;G0H;F5W($QI:V5#<FET97)I82AA='1R
M:6)U=&4L('!A='1E<FXL(&9A;'-E*2D[#0H@("`@("`@('T-"B`@("`@("`@
M96QS90T*("`@("`@("![#0H@("`@("`@("`@("!C<FET97)I82YA9&1%;&5M
M96YT*&YE=R!%<75A;%1O0W)I=&5R:6$H871T<FEB=71E+"!V86QU92DI.PT*
M("`@("`@("!]#0H@("`@?0T*#0H@("`@+RHJ#0H@("`@("H@061D<R!A;F0@
M97%U86QS("@]*2!C<FET97)I82!F;W(@8V]L=6UN(&-O;7!A<FES;VXL#0H@
M("`@("H@8W5S=&]M97)?:60@/2!M>5]I9`T*("`@("`J(#Q0/@T*("`@("`J
M(%=H97)E(%9A;'5E(&ES(&$@<W1R:6YG('-I;7!L92!P871T97)N(&UA=&-H
M:6YG(&-A;B!B92!U<V5D+"!T:&4-"B`@("`@*B!C:&%R86-T97(@*B!I<R!A
M('=I;&1C87)D+"!E+F<N#0H@("`@("H@8W5S=&]M97)?;F%M92`]($%N9&5R
M*@T*("`@("`J(#Q0/@T*("`@("`J(%=O=6QD(&UA=&-H('1H92!C=7-T;VUE
M<G,Z($%N9&5R<V]N(&%N9"!!;F1E<G1O;BX@(%1H92!C:&%R86-T97(@/R!M
M871C:&5S(&$@<VEN9VQE#0H@("`@("H@;V-C=7)E;F-E(&]F(&$@8VAA<F%C
M=&5R+@T*("`@("`J#0H@("`@("H-"B`@("`@*B!`<&%R86T@(&%T=')I8G5T
M92`@(%1H92!F:65L9"!N86UE('1O(&)E('5S960-"B`@("`@*B!`<&%R86T@
M(&-O;$YA;64@("!C;VQU;6YN86UE#0H@("`@("HO#0H@("`@<'5B;&EC('9O
M:60@861D17%U86Q4;T-O;'5M;BA3=')I;F<@871T<FEB=71E+"!3=')I;F<@
M8V]L3F%M92D-"B`@("![#0H@("`@("`@($5Q=6%L5&]#;VQU;6Y#<FET97)I
M82!C(#T@;F5W($5Q=6%L5&]#;VQU;6Y#<FET97)I82AA='1R:6)U=&4L(&-O
M;$YA;64I.PT*("`@("`@("!C<FET97)I82YA9&1%;&5M96YT*&,I.PT*("`@
M('T-"@T*("`@("\J*@T*("`@("`J($%D9',@1W)E871E<D]R17%U86P@5&AA
M;B`H/CTI(&-R:71E<FEA+`T*("`@("`J(&-U<W1O;65R7VED(#X](#$P,#,T
M#0H@("`@("H-"B`@("`@*B!`<&%R86T@(&%T=')I8G5T92`@(%1H92!F:65L
M9"!N86UE('1O(&)E('5S960-"B`@("`@*B!`<&%R86T@('9A;'5E("`@("`@
M($%N(&]B:F5C="!R97!R97-E;G1I;F<@=&AE('9A;'5E(&]F('1H92!F:65L
M9`T*("`@("`J+PT*("`@('!U8FQI8R!V;VED(&%D9$=R96%T97)/<D5Q=6%L
M5&AA;BA3=')I;F<@871T<FEB=71E+"!/8FIE8W0@=F%L=64I#0H@("`@>PT*
M("`@("`@("!'<F5A=&5R3W)%<75A;$-R:71E<FEA(&,@/2!N97<@1W)E871E
M<D]R17%U86Q#<FET97)I82AA='1R:6)U=&4L('9A;'5E*3L-"B`@("`@("`@
M8W)I=&5R:6$N861D16QE;65N="AC*3L-"B`@("!]#0H-"@T*("`@("\J*@T*
M("`@("`J($%D9',@3&5S<T]R17%U86P@5&AA;B`H/#TI(&-R:71E<FEA+`T*
M("`@("`J(&-U<W1O;65R7VED(#P](#$P,#,T#0H@("`@("H-"B`@("`@*B!`
M<&%R86T@(&%T=')I8G5T92`@(%1H92!F:65L9"!N86UE('1O(&)E('5S960-
M"B`@("`@*B!`<&%R86T@('9A;'5E("`@("`@($%N(&]B:F5C="!R97!R97-E
M;G1I;F<@=&AE('9A;'5E(&]F('1H92!F:65L9`T*("`@("`J+PT*("`@('!U
M8FQI8R!V;VED(&%D9$QE<W-/<D5Q=6%L5&AA;BA3=')I;F<@871T<FEB=71E
M+"!/8FIE8W0@=F%L=64I#0H@("`@>PT*("`@("`@("!,97-S3W)%<75A;$-R
M:71E<FEA(&,@/2!N97<@3&5S<T]R17%U86Q#<FET97)I82AA='1R:6)U=&4L
M('9A;'5E*3L-"B`@("`@("`@8W)I=&5R:6$N861D16QE;65N="AC*3L-"B`@
M("!]#0H-"B`@("`O*BH-"B`@("`@*B!!9&1S($QI:V4@*$Q)2T4I(&-R:71E
M<FEA+`T*("`@("`J(&-U<W1O;65R7VED($Q)2T4@,3`P,S0-"B`@("`@*@T*
M("`@("`J($!P87)A;2`@871T<FEB=71E("`@5&AE(&9I96QD(&YA;64@=&\@
M8F4@=7-E9`T*("`@("`J($!P87)A;2`@=F%L=64@("`@("`@06X@;V)J96-T
M(')E<')E<V5N=&EN9R!T:&4@=F%L=64@;V8@=&AE(&9I96QD#0H@("`@("HO
M#0H@("`@<'5B;&EC('9O:60@861D3&EK92A3=')I;F<@871T<FEB=71E+"!/
M8FIE8W0@=F%L=64I#0H@("`@>PT*("`@("`@("!,:6ME0W)I=&5R:6$@8R`]
M(&YE=R!,:6ME0W)I=&5R:6$H871T<FEB=71E+"!V86QU92P@9F%L<V4I.PT*
M("`@("`@("!C<FET97)I82YA9&1%;&5M96YT*&,I.PT*("`@('T-"@T*("`@
M("\J*@T*("`@("`J($%D9',@3&EK92`H3D]4($Q)2T4I(&-R:71E<FEA+`T*
M("`@("`J(&-U<W1O;65R7VED($Y/5"!,24M%(#$P,#,T#0H@("`@("H-"B`@
M("`@*B!`<&%R86T@(&%T=')I8G5T92`@(%1H92!F:65L9"!N86UE('1O(&)E
M('5S960-"B`@("`@*B!`<&%R86T@('9A;'5E("`@("`@($%N(&]B:F5C="!R
M97!R97-E;G1I;F<@=&AE('9A;'5E(&]F('1H92!F:65L9`T*("`@("`J+PT*
M("`@('!U8FQI8R!V;VED(&%D9$YO=$QI:V4H4W1R:6YG(&%T=')I8G5T92P@
M3V)J96-T('9A;'5E*0T*("`@('L-"B`@("`@("`@3&EK94-R:71E<FEA(&,@
M/2!N97<@3&EK94-R:71E<FEA*&%T=')I8G5T92P@=F%L=64L('1R=64I.PT*
M("`@("`@("!C<FET97)I82YA9&1%;&5M96YT*&,I.PT*("`@('T-"@T*("`@
M("\J*@T*("`@("`J($%D9',@3F]T17%U86Q4;R`H/#XI(&-R:71E<FEA+`T*
M("`@("`J(&-U<W1O;65R7VED(#P^(#$P,#,T#0H@("`@("H@/%`^#0H@("`@
M("H@5VAE<F4@5F%L=64@:7,@82!S=')I;F<@<VEM<&QE('!A='1E<FX@;6%T
M8VAI;F<@8V%N(&)E('5S960L('1H90T*("`@("`J(&-H87)A8W1E<B`J(&ES
M(&$@=VEL9&-A<F0L(&4N9RX-"B`@("`@*B!C=7-T;VUE<E]N86UE(#T@06YD
M97(J#0H@("`@("H@/%`^#0H@("`@("H@5V]U;&0@;6%T8V@@=&AE(&-U<W1O
M;65R<SH@06YD97)S;VX@86YD($%N9&5R=&]N+B`@5&AE(&-H87)A8W1E<B`_
M(&UA=&-H97,@82!S:6YG;&4-"B`@("`@*B!O8V-U<F5N8V4@;V8@82!C:&%R
M86-T97(N#0H@("`@("H-"B`@("`@*B!4:&4@)UPG(&-H87)A8W1E<B!I<R!U
M<V5D(&%S(&%N(&5S8V%P92!C:&%R86-T97(@86YD(&%L;&]W('-E87)C:&EN
M9R!F;W(@<W1R:6YG<PT*("`@("`J(&-O;G1A:6YI;F<@*B!O<B`_+B`@4V\@
M:6X@;W)D97(@=&\@<V5A<F-H(&9O<B!!;F1E<BH@+2!U<V4@06YD97)<*BX-
M"B`@("`@*@T*("`@("`J($!P87)A;2`@871T<FEB=71E("`@5&AE(&9I96QD
M(&YA;64@=&\@8F4@=7-E9`T*("`@("`J($!P87)A;2`@=F%L=64@("`@("`@
M06X@;V)J96-T(')E<')E<V5N=&EN9R!T:&4@=F%L=64@;V8@=&AE(&9I96QD
M#0H@("`@("HO#0H@("`@<'5B;&EC('9O:60@861D3F]T17%U86Q4;RA3=')I
M;F<@871T<FEB=71E+"!/8FIE8W0@=F%L=64I#0H@("`@>PT*("`@("`@("!I
M9B`H=F%L=64@:6YS=&%N8V5O9B!3=')I;F<I#0H@("`@("`@('L-"B`@("`@
M("`@("`@("\O('-U8G-T:71U=&4@;W5R('-P96-I86P@8VAA<F%C=&5R(&9O
M<B!344P@=F5R<VEO;G,-"B`@("`@("`@("`@(%-T<FEN9R!P871T97)N(#T@
M9V5N97)A=&5344Q396%R8VA0871T97)N*"A3=')I;F<I=F%L=64I.PT*("`@
M("`@("`@("`@:68@*"AP871T97)N+FEN9&5X3V8H)R4G*2`]/2`M,2D@)B8@
M*'!A='1E<FXN:6YD97A/9B@G7R<I(#T]("TQ*2D-"B`@("`@("`@("`@("`@
M("!C<FET97)I82YA9&1%;&5M96YT*&YE=R!.;W1%<75A;%1O0W)I=&5R:6$H
M871T<FEB=71E+"!P871T97)N*2D[#0H@("`@("`@("`@("!E;'-E#0H@("`@
M("`@("`@("`@("`@8W)I=&5R:6$N861D16QE;65N="AN97<@3&EK94-R:71E
M<FEA*&%T=')I8G5T92P@<&%T=&5R;BP@=')U92DI.PT*("`@("`@("!]#0H@
M("`@("`@(&5L<V4-"B`@("`@("`@>PT*("`@("`@("`@("`@8W)I=&5R:6$N
M861D16QE;65N="AN97<@3F]T17%U86Q4;T-R:71E<FEA*&%T=')I8G5T92P@
M=F%L=64I*3L-"B`@("`@("`@?0T*("`@('T-"@T*("`@("\J*@T*("`@("`J
M($%D9',@1W)E871E<B!4:&%N("@^*2!C<FET97)I82P-"B`@("`@*B!C=7-T
M;VUE<E]I9"`^(#$P,#,T#0H@("`@("H-"B`@("`@*B!`<&%R86T@(&%T=')I
M8G5T92`@(%1H92!F:65L9"!N86UE('1O(&)E('5S960-"B`@("`@*B!`<&%R
M86T@('9A;'5E("`@("`@($%N(&]B:F5C="!R97!R97-E;G1I;F<@=&AE('9A
M;'5E(&]F('1H92!F:65L9`T*("`@("`J+PT*("`@('!U8FQI8R!V;VED(&%D
M9$=R96%T97)4:&%N*%-T<FEN9R!A='1R:6)U=&4L($]B:F5C="!V86QU92D-
M"B`@("I8G5T92P@=F%L=64I.PT*("`@("`@
M("!C<FET97)I82YA9&1%;&5M96YT*&,I.PT*("`@('T-"@T*("`@("\J*@T*
M("`@("`J($%D9',@3&5S<R!4:&%N("@\*2!C<FET97)I82P-"B`@("`@*B!C
M=7-T;VUE<E]I9"`\(#$P,#,T#0H@("`@("H-"B`@("`@*B!`<&%R86T@(&%T
M=')I8G5T92`@(%1H92!F:65L9"!N86UE('1O(&)E('5S960-"B`@("`@*B!`
M<&%R86T@('9A;'5E("`@("`@($%N(&]B:F5C="!R97!R97-E;G1I;F<@=&AE
M('9A;'5E(&]F('1H92!F:65L9`T*("`@("`J+PT*("`@('!U8FQI8R!V;VED
M(&%D9$QE<W-4:&%N*%-T<FEN9R!A='1R:6)U=&4L($]B:F5C="!V86QU92D-
M"B`@("I8G5T92P@=F%L=64I.PT*("`@("`@("!C<FET
M97)I82YA9&1%;&5M96YT*&,I.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J
M($]2<R!T=V\@<V5T<R!O9B!C<FET97)I82!T;V=E=&AE<CH-"B`@("`@*B!A
M8W1I=F4@/2!T<G5E($%.1"!B86QA;F-E(#P@,"!/4B!A8W1I=F4@/2!T<G5E
M($%.1"!O=F5R9')A9G0@/2`P#0H@("`@("H-"B`@("`@*B!`<&%R86T@('!E
M<G-I<W1E;G0@8W)I=&5R:6$-"B`@("`@*B!`=&AR;W=S(%!E<G-I<V5N=$5X
M8V5P=&EO;B!W:&5N('1H97)E(&%R92!N;R!P<F5V:6]U<R!C<FET97)I82!T
M;R!/4B!W:71H#0H@("`@("HO#0H@("`@<'5B;&EC('9O:60@;W)D97)">2A3
M=')I;F<@9FEE;&1.86UE*0T*("`@('L-"B`@("`@("`@;W)D97)B>2`](&9I
M96QD3F%M93L-"B`@("!]#0H-"B`@("!P=6)L:6,@=F]I9"!O<F1E<D)Y*%-T
M<FEN9R!F:65L9$YA;64L(&)O;VQE86X@<V]R=$%S8V5N9&EN9RD-"B`@("![
M#0H@("`@("`@(&]R9&5R8GD@/2!F:65L9$YA;64[#0H@("`@("`@(&%S8V5N
M9&EN9R`]('-O<G1!<V-E;F1I;F<[#0H@("`@?0T*#0H@("`@<'5B;&EC(&)O
M;VQE86X@:7-!<V-E;F1I;F<H*0T*("`@('L-"B`@("`@("`@<F5T=7)N(&%S
M8V5N9&EN9SL-"B`@("!]#0H-"B`@("`O*BH-"B`@("`@*B!-971H;V0@9&5C
M;&%R871I;VX-"B`@("`@*@T*("`@("`J#0H@("`@("H@0')E='5R;@T*("`@
M("`J#0H@("`@("H-"B`@("`@*B\-"B`@("!P=6)L:6,@4W1R:6YG(&=E=$]R
M9&5R8GDH*0T*("`@('L-"B`@("`@("`@<F5T=7)N(&]R9&5R8GD[#0H@("`@
M?0T*#0H@("`@+RHJ#0H@("`@("H@365T:&]D(&1E8VQA<F%T:6]N#0H@("`@
M("H-"B`@("`@*@T*("`@("`J($!R971U<FX-"B`@("`@*@T*("`@("`J#0H@
M("`@("HO#0H@("`@<'5B;&EC(%-T<FEN9R!T;U-T<FEN9R@I#0H@("`@>PT*
M("`@("`@("!R971U<FX@4W%L1V5N97)A=&]R+F=E=$EN<W1A;F-E*"DN87-3
M44Q3=&%T96UE;G0H=&AI<RP@;G5L;"D[#0H@("`@?0T*#0H@("`@+RHJ#0H@
M("`@("H@3U)S('1W;R!S971S(&]F(&-R:71E<FEA('1O9V5T:&5R.@T*("`@
M("`J(&%C=&EV92`]('1R=64@04Y$(&)A;&%N8V4@/"`P($]2(&%C=&EV92`]
M('1R=64@04Y$(&]V97)D<F%F="`](#`-"B`@("`@*B!`<&%R86T@('!E<G-I
M<W1E;G0@8W)I=&5R:6$-"B`@("`@*B\-"B`@("!P=6)L:6,@=F]I9"!A9&1/
M<D-R:71E<FEA*$-R:71E<FEA('!C*0T*("`@('L-"@T*("`@("`@("!I9B`H
M(6-R:71E<FEA+FES16UP='DH*2D-"B`@("`@("`@>PT*("`@("`@("`@("`@
M<&,N<V5T16UB<F%C960H9F%L<V4I.PT*("`@("`@("`@("`@<&,N<V5T5'EP
M92A/4BD[#0H@("`@("`@("`@("!C<FET97)I82YA9&1%;&5M96YT*'!C*3L-
M"B`@("`@("`@?0T*("`@("`@("!E;'-E#0H@("`@("`@('L-"B`@("`@("`@
M("`@('-E=$5M8G)A8V5D*&9A;'-E*3L-"B`@("`@("`@("`@('-E=%1Y<&4H
M3D].12D[("\O(')O;W0@;V)J96-T#0H@("`@("`@("`@("!C<FET97)I82`]
M('!C+F=E=$-R:71E<FEA*"D[#0H@("`@("`@('T-"B`@("!]#0H-"B`@("`O
M*BH-"B`@("`@*B!!9&1S(&ES($YU;&P@8W)I=&5R:6$L#0H@("`@("H@8W5S
M=&]M97)?:60@:7,@3G5L;`T*("`@("`J#0H@("`@("H@0'!A<F%M("!A='1R
M:6)U=&4@("!4:&4@9FEE;&0@;F%M92!T;R!B92!U<V5D#0H@("`@("HO#0H@
M("`@<'5B;&EC('9O:60@861D27-.=6QL*%-T<FEN9R!A='1R:6)U=&4I#0H@
M("`@>PT*("`@("`@("!C<FET97)I82YA9&1%;&5M96YT*&YE=R!.=6QL0W)I
M=&5R:6$H871T<FEB=71E+"!F86QS92DI.PT*("`@('T-"@T*("`@("\J*@T*
M("`@("`J($%D9',@;F]T($YU;&P@8W)I=&5R:6$L#0H@("`@("H@8W5S=&]M
M97)?:60@:7,@;F]T($YU;&P-"B`@("`@*@T*("`@("`J($!P87)A;2`@871T
M<FEB=71E("`@5&AE(&9I96QD(&YA;64@=&\@8F4@=7-E9`T*("`@("`J+PT*
M("`@('!U8FQI8R!V;VED(&%D9$YO=$YU;&PH4W1R:6YG(&%T=')I8G5T92D-
M"B`@("![#0H@("`@("`@(&-R:71E<FEA+F%D9$5L96UE;G0H;F5W($YU;&Q#
M<FET97)I82AA='1R:6)U=&4L('1R=64I*3L-"B`@("!]#0H-"B`@("`O*BH-
M"B`@("`@*B!!9&1S($)%5%=%14X@8W)I=&5R:6$L#0H@("`@("H@8W5S=&]M
M97)?:60@8F5T=V5E;B`Q(&%N9"`Q,`T*("`@("`J#0H@("`@("H@0'!A<F%M
M("!A='1R:6)U=&4@("!4:&4@9FEE;&0@;F%M92!T;R!B92!U<V5D#0H@("`@
M("H@0'!A<F%M("!V86QU93$@("!4:&4@;&]W97(@8F]U;F1A<GD-"B`@("`@
M*B!`<&%R86T@('9A;'5E,B`@(%1H92!U<'!E<B!B;W5N9&%R>0T*("`@("`J
M+PT*("`@('!U8FQI8R!V;VED(&%D9$)E='=E96XH4W1R:6YG(&%T=')I8G5T
M92P@3V)J96-T('9A;'5E,2P@3V)J96-T('9A;'5E,BD-"B`@("![#0H@("`@
M("`@(&-R:71E<FEA+F%D9$5L96UE;G0H;F5W($)E='=E96Y#<FET97)I82AA
M='1R:6)U=&4L('9A;'5E,2P@=F%L=64R+"!F86QS92DI.PT*("`@('T-"@T*
M("`@("\J*@T*("`@("`J($%D9',@3D]4($)%5%=%14X@8W)I=&5R:6$L#0H@
M("`@("H@8W5S=&]M97)?:60@;F]T(&)E='=E96X@,2!A;F0@,3`-"B`@("`@
M*@T*("`@("`J($!P87)A;2`@871T<FEB=71E("`@5&AE(&9I96QD(&YA;64@
M=&\@8F4@=7-E9`T*("`@("`J($!P87)A;2`@=F%L=64Q("`@5&AE(&QO=V5R
M(&)O=6YD87)Y#0H@("`@("H@0'!A<F%M("!V86QU93(@("!4:&4@=7!P97(@
M8F]U;F1A<GD-"B`@("`@*B\-"B`@("!P=6)L:6,@=F]I9"!A9&1.;W1"971W
M965N*%-T<FEN9R!A='1R:6)U=&4L($]B:F5C="!V86QU93$L($]B:F5C="!V
M86QU93(I#0H@("`@>PT*("`@("`@("!C<FET97)I82YA9&1%;&5M96YT*&YE
M=R!"971W965N0W)I=&5R:6$H871T<FEB=71E+"!V86QU93$L('9A;'5E,BP@
M=')U92DI.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J($%D9',@24X@8W)I
M=&5R:6$L#0H@("`@("H@8W5S=&]M97)?:60@:6XH,2PQ,"PS,RD-"B`@("`@
M*@T*("`@("`J($!P87)A;2`@871T<FEB=71E("`@5&AE(&9I96QD(&YA;64@
M=&\@8F4@=7-E9`T*("`@("`J($!P87)A;2`@=F%L=64@("!4:&4@=F%L=64@
M0V]L;&5C=&EO;@T*("`@("`J+PT*("`@('!U8FQI8R!V;VED(&%D9$EN*%-T
M<FEN9R!A='1R:6)U=&4L($-O;&QE8W1I;VX@=F%L=65S*0T*("`@('L-"B`@
M("`@("`@8W)I=&5R:6$N861D16QE;65N="AN97<@26Y#<FET97)I82AA='1R
M:6)U=&4L('9A;'5E<RP@9F%L<V4I*3L-"B`@("!]#0H-"B`@("`O*BH-"B`@
M("`@*B!!9&1S($Y/5"!)3B!C<FET97)I82P-"B`@("`@*B!C=7-T;VUE<E]I
M9"!N;W0@:6XH,2PQ,"PS,RD-"B`@("`@*@T*("`@("`J($!P87)A;2`@871T
M<FEB=71E("`@5&AE(&9I96QD(&YA;64@=&\@8F4@=7-E9`T*("`@("`J($!P
M87)A;2`@=F%L=64@("!4:&4@=F%L=64@0V]L;&5C=&EO;@T*("`@("`J+PT*
M("`@('!U8FQI8R!V;VED(&%D9$YO=$EN*%-T<FEN9R!A='1R:6)U=&4L($-O
M;&QE8W1I;VX@=F%L=65S*0T*("`@('L-"B`@("`@("`@8W)I=&5R:6$N861D
M16QE;65N="AN97<@26Y#<FET97)I82AA='1R:6)U=&4L('9A;'5E<RP@=')U
M92DI.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J($%D9',@9G)E969O<FT@
M4U%,(&-R:71E<FEA+`T*("`@("`J(%)%5D524T4H;F%M92D@;&EK92`G<F4E
M)PT*("`@("`J#0H@("`@("H@0'!A<F%M("!A;E-Q;%-T871M96YT("`@5&AE
M(&9R964@9F]R;2!344PM4W1A=&5M96YT#0H@("`@("HO#0H@("`@<'5B;&EC
M('9O:60@861D4W%L*%-T<FEN9R!A;E-Q;%-T871M96YT*0T*("`@('L-"B`@
M("`@("`@8W)I=&5R:6$N861D16QE;65N="AN97<@4W%L0W)I=&5R:6$H86Y3
M<6Q3=&%T;65N="DI.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J($%.1',@
M='=O('-E=',@;V8@8W)I=&5R:6$@=&]G971H97(Z#0H@("`@("H-"B`@("`@
M*B!`<&%R86T@('!E<G-I<W1E;G0@8W)I=&5R:6$-"B`@("`@*B\-"B`@("!P
M=6)L:6,@=F]I9"!A9&1!;F1#<FET97)I82A#<FET97)I82!P8RD-"B`@("![
M#0H@("`@("`@("\O(&)Y(&-O;6)I;FEN9R!A('-E8V]N9"!C<FET97)I82!B
M>2`G04Y$)R!T:&4@97AI<W1I;F<@8W)I=&5R:6$@;F5E9',@=&\@8F4@96YC
M;&]S960-"B`@("`@("`@+R\@:6X@<&%R96YT:&5S:7,-"B`@("`@("`@:68@
M*"%C<FET97)I82YI<T5M<'1Y*"DI#0H@("`@("`@('L-"B`@("`@("`@("`@
M('1H:7,N<V5T16UB<F%C960H=')U92D[#0H@("`@("`@("`@("!P8RYS971%
M;6)R86-E9"AT<G5E*3L-"B`@("`@("`@("`@('!C+G-E=%1Y<&4H04Y$*3L-
M"B`@("`@("`@("`@(&-R:71E<FEA+F%D9$5L96UE;G0H<&,I.PT*("`@("`@
M("!]#0H@("`@("`@(&5L<V4-"B`@("`@("`@>PT*("`@("`@("`@("`@<V5T
M16UB<F%C960H9F%L<V4I.PT*("`@("`@("`@("`@<V5T5'EP92A.3TY%*3L@
M+R\@<F]O="!O8FIE8W0-"B`@("`@("`@("`@(&-R:71E<FEA(#T@<&,N9V5T
M0W)I=&5R:6$H*3L-"B`@("`@("`@?0T*("`@('T-"@T*("`@("\J*@T*("`@
M("`J($%D9',@86X@97AI<W1S*'-U8B!Q=65R>2D-"B`@("`@*@T*("`@("`J
M($!P87)A;2!S=6)1=65R>2!S=6(M<75E<GD-"B`@("`@*B\-"B`@("!P=6)L
M:6,@=F]I9"!A9&1%>&ES=',H475E<GD@<W5B475E<GDI('L-"B`@("`@("`@
M8W)I=&5R:6$N861D16QE;65N="AN97<@17AI<W1S0W)I=&5R:6$H<W5B475E
M<GDL(&9A;'-E*2D[#0H@("`@?0T*#0H@("`@+RHJ#0H@("`@("H@061D<R!A
M(&YO="!E>&ES=',H<W5B('%U97)Y*0T*("`@("`J#0H@("`@("H@0'!A<F%M
M('-U8E%U97)Y('-U8BUQ=65R>0T*("`@("`J+PT*("`@('!U8FQI8R!V;VED
M(&%D9$YO=$5X:7-T<RA1=65R>2!S=6)1=65R>2D@>PT*("`@("`@("!C<FET
M97)I82YA9&1%;&5M96YT*&YE=R!%>&ES='-#<FET97)I82AS=6)1=65R>2P@
M=')U92DI.PT*("`@('T-"@T*("`@("\J*@T*("`@("`J($EN<V5R="!T:&4@
M;65T:&]D)W,@9&5S8W)I<'1I;VX@:&5R92X-"B`@("`@*B!#<F5A=&EO;B!D
M871E.B`H,#@N,#4N,#$@,34Z,#<Z-#$I#0H@("`@("H@0')E='5R;B!B;V]L
M96%N#0H@("`@("HO#0H@("`@<'5B;&EC(&)O;VQE86X@:7-%;7!T>2@I#0H@
M("`@>PT*("`@("`@("!R971U<FX@8W)I=&5R:6$N:7-%;7!T>2@I.PT*("`@
M('T-"B`@("`-"B`@("`O*BH-"B`@("`@*B!'96YE<F%T92!A(%-13"!S96%R
M8V@@<W1R:6YG(&9R;VT@=&AE('!A='1E<FX@<W1R:6YG('!A<W-E9"X-"B`@
M("`@*B!4:&4@<&%T=&5R;B!S=')I;F<@:7,@82!S:6UP;&4@<&%T=&5R;B!S
M=')I;F<@=7-I;F<@*B!A<R!A('=I;&1C87)D+@T*("`@("`J(%-O($%N9&5R
M*B!W;W5L9"!M871C:"!!;F1E<G-O;B!A;F0@06YD97)T;VXN#0H@("`@("H@
M5&AE(#\@8VAA<F%C=&5R(&ES('5S960@=&\@;6%T8V@@82!S:6YG;&4@;V-C
M=7)E;F-E(&]F(&$@8VAA<F%C=&5R+@T*("`@("`J(%1H92`G7"<@:7,@=7-E
M9"!T;R!E<V-A<&4@=&AE('=I;&0@8V%R9"!C:&%R86-T97)S('-O('1H870@
M=V4-"B`@("`@*B!C86X@<V5A<F-H(&9O<B!S=')I;F=S(&-O;G1A:6YI;F<@
M*B!A;F0@/RX-"B`@("`@*B!4:&ES(&UE=&AO9"!C;VYV97)T<R!T:&4@8W)I
M=&5R:6$@=VEL9&-A<F0@<W1R:6YG<R!T;R!344P@=VEL9&-A<F1S+@T*("`@
M("`J#0H@("`@("H@0'!A<F%M('!A='1E<FX@82!C<FET97)I82!S96%R8V@@
M<&%T=&5R;B!C;VYT86EN:6YG(&]P=&EO;F%L('=I;&1C87)D<R`-"B`@("`@
M*B!`<F5T=7)N(&$@4U%,('-E87)C:"!P871T97)N('-T<FEN9R!W:71H(&%L
M;"!E<V-A<&4@8V]D97,@<')O8V5S<V5D+B`-"B`@("`@*B\-"B`@("!3=')I
M;F<@9V5N97)A=&5344Q396%R8VA0871T97)N*%-T<FEN9R!P871T97)N*0T*
M("`@('L-"B`@("`@("`@4W1R:6YG0G5F9F5R('-Q;'!A='1E<FX@/2!N97<@
M4W1R:6YG0G5F9F5R*"D[#0H-"B`@("`@("`@8VAA<EM=(&-H87)S(#T@<&%T
M=&5R;BYT;T-H87)!<G)A>2@I.PT*("`@("`@("!F;W(@*&EN="!I(#T@,#L@
M:2`\(&-H87)S+FQE;F=T:#L@:2LK*0T*("`@("`@("![#0H@("`@("`@("`@
M("!I9B`H8VAA<G-;:5T@/3T@)UQ<)RD-"B`@("`@("`@("`@('L-"B`@("`@
M("`@("`@("`@("`O+R!F;W(@=&AE(&5S8V%P92!C:&%R86-T97(@861D('1H
M92!N97AT(&-H87(@87,@:7,N#0H@("`@("`@("`@("`@("`@:68@*"LK:2`\
M(&-H87)S+FQE;F=T:"D-"B`@("`@("`@("`@("`@("`@("`@<W%L<&%T=&5R
M;BYA<'!E;F0H8VAA<G-;:5TI.PT*("`@("`@("`@("`@?0T*("`@("`@("`@
M("`@96QS92!I9B`H8VAA<G-;:5T@/3T@)RHG*0T*("`@("`@("`@("`@("`@
M('-Q;'!A='1E<FXN87!P96YD*"(E(BD[#0H@("`@("`@("`@("!E;'-E(&EF
M("AC:&%R<UMI72`]/2`G/R<I#0H@("`@("`@("`@("`@("`@<W%L<&%T=&5R
M;BYA<'!E;F0H(E\B*3L-"B`@("`@("`@("`@(&5L<V4-"B`@("`@("`@("`@
M("`@("!S<6QP871T97)N+F%P<&5N9"AC:&%R<UMI72D[#0H@("`@("`@('T-
M"B`@("`@("`@<F5T=7)N('-Q;'!A='1E<FXN=&]3=')I;F<H*3L-"B`@("!]
%#0I]#0HM
`
end
|
|
From: Darren S. <Dar...@cw...> - 2002-02-21 13:44:34
|
Thomas, A couple of questions: - Isn't this kind of code going to have to replicated throughout the entire framework - wherever createPersistenceBroker is called ? - Shouldn't the releaseInstance be done within a finally block to ensure the broker is released in the event of an exception being thrown ? Regards Darren |--------+----------------------------> | | Mahler Thomas | | | <thomas.mahler@ite| | | llium.com> | | | | | | 02/21/02 09:40 AM | | | | |--------+----------------------------> >----------------------------------------------------------------------------| | | | To: 'Ricardo Argello' <ri...@ya...>, Alex Cruise | | <ac...@in...>, "Objectbridge (E-Mail)" | | <obj...@li...> | | cc: (bcc: Darren Syzling/London/CWB) | | Subject: AW: [OJB-developers] ERROR: Server configuration denies | | access to data source | >----------------------------------------------------------------------------| Hi Ricardo, I had a look at the Proxy stuff. I believe that there is a bug in the Class ojb.broker.accesslayer.IndirectionHandler. Please replace the method materializeSubject with the following code: private synchronized void materializeSubject() throws PersistenceBrokerException { beforeMaterialization(); realSubject = getBroker().getObjectByIdentity(id); // release broker after use !!! PersistenceBrokerFactory.releaseInstance(broker); if (realSubject == null) { LoggerFactory.getDefaultLogger().warn("OJB broker could not materialize " + id.toString()); } afterMaterialization(); } The Problem: With the new feature of a pool of brokers in the the PersistenceBrokerFactory all obtained instances must be released after use! The InvovationHandler just not did this. Thus the PersistenceBrokerFactory generated tons of fresh broker instances that all have their own JDBC connections. Please tell me if this patch fixes you problem. Thomas > -----Ursprngliche Nachricht----- > Von: Ricardo Argello [mailto:ri...@ya...] > Gesendet: Donnerstag, 21. Februar 2002 00:54 > An: Alex Cruise; Objectbridge (E-Mail) > Betreff: Re: [OJB-developers] ERROR: Server configuration > denies access > to data source > > > > After I got this exception, I tried to login to the database > using the "mysql" command line program, and it gave me this error: > > ERROR 1040: Too many connections > > Thant's why I'm sure it's a connection limit problem. > > Thanks! > > Ricardo > > > > ----- Original Message ----- > From: "Alex Cruise" <ac...@in...> > To: "Objectbridge (E-Mail)" > <obj...@li...> > Sent: Wednesday, February 20, 2002 5:48 PM > Subject: RE: [OJB-developers] ERROR: Server configuration > denies access to data source > > > From: Ricardo Argello [mailto:ri...@ya...] > > > It turns out that this error: > > java.sql.SQLException: Server configuration denies access > > to data source > > > > was caused because MySql used its "max_connections" limit of 100. > > > > I tried to initialize MySql with a parameter of > > max_connections=1000, but it gave me the same error. > > Are you sure? I usually see this error when there's a > permissions problem. > > -0xe1a > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Darren S. <Dar...@cw...> - 2002-02-21 09:45:41
|
Hi Ricardo, I've noticed some behavior with the PersistenceBrokerFactory that I've been meaning to bring up... Testing with Object Bridge (raw PersistenceBroker and not the ODMG interfaces) I've found that a broker instance will be created for each call to createPersistenceBroker. Now I know there's some pooling code been added, but release is required for the pooling to work effectively which so far is only called from within the odmg transaction code. For each broker instance I think we also get a ConnectionManager which leads to multiple caches of connections for the JdbcConnectionDescriptor. For our tests we were constantly connecting and reconnecting to the database and connections were not efficiently being pooled. For the time being in our own local copy of the code I've made the persistence broker a singleton to be certain about the number of connections we're creating. I know this is not a general solution but solves our pressing need. I haven't had the time to take a detailed look at the code, and I'm initially confused by the intention of the broker and how it relates to the repository, connection manager etc. It really boils down to an ownership issue and the intent of the design. I know when I first looked at Object Bridge I was asking myself quite a few questions about the ownership and relationships of objects related to the broker instance. For example, does a broker relate to a single repository ? Can I create multiple brokers each with their own repository (and perhaps ojb.properties) ? The problem also seems to stem from the fact that external clients of the broker - either users of the raw broker or persistence layers (such as JDO or ODMG) call the factory to create a broker. But also in performing persistence mapping operations (say during broker.store), the same call is made for convenience to grab hold of a broker to help implement the required operation. This leads me to think in our scenario we create a broker instance - that instance may be used to cache connections etc. We call store which then creates other broker instances, those are used to perform the persistence which then detect they haven't any cached connections, so connect. These newly created brokers (with their connections) drift out of scope - the cycle starts again for the next transaction. Regards Darren |--------+-----------------------> | | Ricardo | | | Argello | | | <ricardo@yage| | | .com.ec> | | | | | | 02/20/02 | | | 11:54 PM | | | | |--------+-----------------------> >----------------------------------------------------------------------------| | | | To: "Alex Cruise" <ac...@in...>, "Objectbridge | | \(E-Mail\)" <obj...@li...> | | cc: (bcc: Darren Syzling/London/CWB) | | Subject: Re: [OJB-developers] ERROR: Server configuration denies | | access to data source | >----------------------------------------------------------------------------| After I got this exception, I tried to login to the database using the "mysql" command line program, and it gave me this error: ERROR 1040: Too many connections Thant's why I'm sure it's a connection limit problem. Thanks! Ricardo ----- Original Message ----- From: "Alex Cruise" <ac...@in...> To: "Objectbridge (E-Mail)" <obj...@li...> Sent: Wednesday, February 20, 2002 5:48 PM Subject: RE: [OJB-developers] ERROR: Server configuration denies access to data source From: Ricardo Argello [mailto:ri...@ya...] > It turns out that this error: > java.sql.SQLException: Server configuration denies access > to data source > > was caused because MySql used its "max_connections" limit of 100. > > I tried to initialize MySql with a parameter of > max_connections=1000, but it gave me the same error. Are you sure? I usually see this error when there's a permissions problem. -0xe1a _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Mahler T. <tho...@it...> - 2002-02-21 09:41:08
|
Hi Ricardo,
I had a look at the Proxy stuff. I believe that there is a bug in the =
Class
ojb.broker.accesslayer.IndirectionHandler.
Please replace the method materializeSubject with the following code:
private synchronized void materializeSubject() throws
PersistenceBrokerException
{
beforeMaterialization();
realSubject =3D getBroker().getObjectByIdentity(id);
// release broker after use !!!
PersistenceBrokerFactory.releaseInstance(broker);
if (realSubject =3D=3D null)
{
LoggerFactory.getDefaultLogger().warn("OJB broker could not
materialize " + id.toString());
}
afterMaterialization();
}
The Problem: With the new feature of a pool of brokers in the the
PersistenceBrokerFactory all obtained instances must be released after =
use!
The InvovationHandler just not did this.
Thus the PersistenceBrokerFactory generated tons of fresh broker =
instances
that all have their own JDBC connections.
Please tell me if this patch fixes you problem.
Thomas
> -----Urspr=FCngliche Nachricht-----
> Von: Ricardo Arg=FCello [mailto:ri...@ya...]
> Gesendet: Donnerstag, 21. Februar 2002 00:54
> An: Alex Cruise; Objectbridge (E-Mail)
> Betreff: Re: [OJB-developers] ERROR: Server configuration=20
> denies access
> to data source
>=20
>=20
>=20
> After I got this exception, I tried to login to the database=20
> using the "mysql" command line program, and it gave me this error:
>=20
> ERROR 1040: Too many connections
>=20
> Thant's why I'm sure it's a connection limit problem.
>=20
> Thanks!
>=20
> Ricardo
>=20
>=20
>=20
> ----- Original Message -----=20
> From: "Alex Cruise" <ac...@in...>
> To: "Objectbridge (E-Mail)"=20
> <obj...@li...>
> Sent: Wednesday, February 20, 2002 5:48 PM
> Subject: RE: [OJB-developers] ERROR: Server configuration=20
> denies access to data source
>=20
>=20
> From: Ricardo Arg=FCello [mailto:ri...@ya...]
>=20
> > It turns out that this error:
> > java.sql.SQLException: Server configuration denies access=20
> > to data source
> >=20
> > was caused because MySql used its "max_connections" limit of 100.
> >=20
> > I tried to initialize MySql with a parameter of=20
> > max_connections=3D1000, but it gave me the same error.
>=20
> Are you sure? I usually see this error when there's a=20
> permissions problem.
>=20
> -0xe1a
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
|
|
From: Thomas M. <tho...@ho...> - 2002-02-21 06:07:43
|
Hi Eric, You can always trust Jakobs patches. He contributes hiqh quality stuff that is in sync with my overall OJB design! The patch you are referring to is already on my list for integration! (Of course there could still be MINOR changes to some details) cu, Thomas Eric Bieschke wrote: > Is this supported patch? If so, will it be integrated into future versions > of OJB? > > - Eric > > > ----- Original Message ----- > From: "Jakob Braeuchi" <jbr...@ho...> > To: <obj...@li...> > Date: Sun, 17 Feb 2002 10:55:20 +0100 > Subject: [OJB-developers] OJB enhancements to 07.343 > > hi, > > the attached zip contains several enhancements to version 07.343: > > - deferred loading (lazy) for 1:1 relationships > - wasNull when reading from ResultSet > - platform cacheing > - platform functions for setObject(), setNull() > - a MySql platform to fix setObject for Types.BIT > - StatementManager bindInsert and bindUpdate use platform functions now > > the most important feature is deferred loading for 1:1 relationships. it's > based on DynamicProxies and thus requires you to implement an interface for > the target side of the relationship (referenced.class). to enable it, use > <proxyReference>true</proxyReference> in ReferenceDescriptor: > > <ReferenceDescriptor id="1"> > <rdfield.name>partner</rdfield.name> > <referenced.class>brj.ojb.Person</referenced.class> > <fk_descriptor_ids>9</fk_descriptor_ids> > <proxyReference>true</proxyReference> > </ReferenceDescriptor> > > for consistency i also renamed <proxy> to <proxyCollection> for > CollectionDescriptor. > > jakob > > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: <ri...@ya...> - 2002-02-20 23:53:54
|
After I got this exception, I tried to login to the database using the = "mysql" command line program, and it gave me this error: ERROR 1040: Too many connections Thant's why I'm sure it's a connection limit problem. Thanks! Ricardo ----- Original Message -----=20 From: "Alex Cruise" <ac...@in...> To: "Objectbridge (E-Mail)" = <obj...@li...> Sent: Wednesday, February 20, 2002 5:48 PM Subject: RE: [OJB-developers] ERROR: Server configuration denies access = to data source From: Ricardo Arg=FCello [mailto:ri...@ya...] > It turns out that this error: > java.sql.SQLException: Server configuration denies access=20 > to data source >=20 > was caused because MySql used its "max_connections" limit of 100. >=20 > I tried to initialize MySql with a parameter of=20 > max_connections=3D1000, but it gave me the same error. Are you sure? I usually see this error when there's a permissions = problem. -0xe1a _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: <ri...@ya...> - 2002-02-20 23:39:32
|
I'm sure, because "<class.proxy>dynamic</class.proxy>" is the only thing = I changed in the repository.xml file (all my classes implement an = interface). I can login to my web application, but when I try to open a long list of = customers, it gives me the exception. Ricardo ----- Original Message -----=20 From: "Alex Cruise" <ac...@in...> To: "Objectbridge (E-Mail)" = <obj...@li...> Sent: Wednesday, February 20, 2002 5:48 PM Subject: RE: [OJB-developers] ERROR: Server configuration denies access = to data source From: Ricardo Arg=FCello [mailto:ri...@ya...] > It turns out that this error: > java.sql.SQLException: Server configuration denies access=20 > to data source >=20 > was caused because MySql used its "max_connections" limit of 100. >=20 > I tried to initialize MySql with a parameter of=20 > max_connections=3D1000, but it gave me the same error. Are you sure? I usually see this error when there's a permissions = problem. -0xe1a _______________________________________________ Objectbridge-developers mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Eric B. <EBi...@sa...> - 2002-02-20 23:23:59
|
Is this supported patch? If so, will it be integrated into future versions
of OJB?
- Eric
----- Original Message -----
From: "Jakob Braeuchi" <jbr...@ho...>
To: <obj...@li...>
Date: Sun, 17 Feb 2002 10:55:20 +0100
Subject: [OJB-developers] OJB enhancements to 07.343
hi,
the attached zip contains several enhancements to version 07.343:
- deferred loading (lazy) for 1:1 relationships
- wasNull when reading from ResultSet
- platform cacheing
- platform functions for setObject(), setNull()
- a MySql platform to fix setObject for Types.BIT
- StatementManager bindInsert and bindUpdate use platform functions now
the most important feature is deferred loading for 1:1 relationships. it's
based on DynamicProxies and thus requires you to implement an interface for
the target side of the relationship (referenced.class). to enable it, use
<proxyReference>true</proxyReference> in ReferenceDescriptor:
<ReferenceDescriptor id="1">
<rdfield.name>partner</rdfield.name>
<referenced.class>brj.ojb.Person</referenced.class>
<fk_descriptor_ids>9</fk_descriptor_ids>
<proxyReference>true</proxyReference>
</ReferenceDescriptor>
for consistency i also renamed <proxy> to <proxyCollection> for
CollectionDescriptor.
jakob
|
9 messages has been excluded from this view by a project administrator.
