Re: IllegalAccess error setting field in db-ojb-1.0.3
Hi Rajesh,
Rajesh T V wrote:
Hi Armin,
Thanks for your reply.Reply inline.
-Rajesh
does OJB log a more detailed error message?
no
Please search for this message in your log file again. If you use OJB
1.0.3 or higher OJB will log a detailed error message before the
exception was thrown.
For 1.0.3 it begins with try to set 'object value' in 'target
object... or something similar.
Please post the whole stack trace with the logging messages before the
exception occur.
regards,
Armin
Is class UserAccount an interface?
no. UserAccount is an abstract class
public abstract class UserAccount extends some other class
In the reference-descriptor of
EndUser the specified class is IPCEUserAccount. Is it guaranteed that
IPCEUserAccount instances are always sub-classes of UserAccount?
yes. public class IPCEUserAccount extends UserAccount
regards,
Armin
On 4/27/06, Rajesh T V [EMAIL PROTECTED] wrote:
Hi,
We are hitting an intermittent issue with db-ojb-1.0.3.
At random times we hit the following exception while ojb
tries to create an object from a Derby db.
org.apache.ojb.broker.PersistenceBrokerException:
org.apache.ojb.broker.metadata.MetadataException: IllegalAccess error
setting field:userAccount in
object:com.cisco.ipce.engine.datamodel.EndUser
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery
(Unknown
Source)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery
(Unknown
Source)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery
(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery
(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery
(Unknown
Source)
at com.cisco.ipce.engine.sal.dataaccess.DBDAO.get(DBDAO.java:367)
The root cause being a
Caused by: java.lang.IllegalArgumentException at
sun.reflect.UnsafeObjectFieldAccessorImpl.set(
UnsafeObjectFieldAccessorImpl.java:63)
at java.lang.reflect.Field.set(Field.java:656)
... 59 more
The error occurs on different classes at different times. Once we hit
the error, it does
not go away no matter what we do (tomcat restart etc). Once the
problem stops happening
(sometimes on pc restart) it never happens again for a long time.
Our repository_user.xml for all classes are similar.
class-descriptor class=com.cisco.ipce.engine.datamodel.EndUser
table=UserBase
field-descriptor column=OID jdbc-type=INTEGER name=OID
autoincrement=true primarykey=true/
field-descriptor column=userAccountId jdbc-type=INTEGER
name=userAccountId/
reference-descriptor name=userAccount
class-ref=com.cisco.ipce.engine.datamodel.IPCEUserAccount
auto-retrieve=true auto-update=object auto-delete=object
foreignkey field-ref=userAccountId/
/reference-descriptor
field-descriptor column=type jdbc-type=INTEGER name=type/
public class EndUser extends UserBase {
...
...
}
public abstract class UserBase extends IPCEObject{
...
protected UserAccount userAccount;
...
}
I am not sure what we are doing wrong and even if we are why is the
error intermittent ?
All classes where the error occurs have the same pattern where a
protected attribute
of the super-class is being set via the sub-class repository_user.xml
entry. The attribute
is always an auto-retrieve=true; auto-update=object and
auto-delete=object class to
which the offending class holds a foreign key.
Any help appreciated.
Thanks,
Rajesh
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: inner join n:1 how to
Hi, [EMAIL PROTECTED] wrote: Normally , if i use QueryByCriteria q = QueryFactory.newQuery(ProductImpl.class, criteria); and criteria contained some ProductGroup conditions ; and then i will retrieve all data of ProductImpl that product table outter join with ProductGroup table . May be in this case i HAVE to use ReportQuery ? I'm not a query expert, but I think you are right. If you want to mix columns of different tables (/objects) you can't use the object based criteria api. You can find an example here http://db.apache.org/ojb/docu/guides/query.html#Report+Queries regards, Armin Thank in advanced , Regards -- View this message in context: http://www.nabble.com/inner-join-n%3A1-how-to-t1509312.html#a4133579 Sent from the Apache DB - ObjectRelationalBridge Users forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: standalone getDefaultBroker auto-retrieve
Yep. I did something like... with an immediate catched exception!! it
works...
I add a method into PersistenceBrokerFactory to artificially fire all the
finalize methods. This method call releaseAllInstances and System.gc(). then
Finalize are all fired. It works well.
Will release 1.0.5 come out soon? I need the release with circular
references update.
else, is there a downloadable nightly build.
Thanks a lot.
Regards
On 4/28/06, Armin Waibel [EMAIL PROTECTED] wrote:
Hi Bruno,
below you can find #setClosed(...) and #finalize() of the modified PB
source (will check in this in a few days).
regards,
Armin
/**
* A stack trace of this broker user.
* Used when broker leak detection is enabled.
*/
protected String brokerStackTrace;
public void setClosed(boolean closed)
{
// When lookup the PB instance from pool method setClosed(false)
// was called before returning instance from pool, in this case
// OJB have to refresh the instance.
if(!closed)
{
refresh();
// configurable boolean
if(brokerLeakDetection)
{
brokerStackTrace = ExceptionUtils.getFullStackTrace(
new Exception(PersistenceBroker caller stack));
}
}
this.isClosed = closed;
}
protected void finalize()
{
try
{
super.finalize();
// if not closed == broker leak detected
if (!isClosed)
{
String msg = Garbage collection: Unclosed
PersistenceBroker instance detected, check code for PB leaks.;
if(brokerLeakDetection)
{
logger.error(msg + Broker caller stack is:
+ SystemUtils.LINE_SEPARATOR + brokerStackTrace);
}
else
{
logger.warn(msg);
}
close();
}
}
catch(Throwable ignore)
{
// ignore
}
}
Bruno CROS wrote:
Hi Armin, thanks for solution , but i'm not sure i did get it all !!
Can you confirm solution?
Well, i understand i have to override setCLosed method to catch when
broker
open (is borrowed), throw an exception to save a stacktrace with a
catch.
So , PB remembers his last loan. that's it ?
When finalize is done (that means application is ended ?), if broker is
not
closed (how does i known that ?), i have to retrieve the last stored
loan
stacktrace, log it and (why not) throw an BrokerNotClosedException.
That's
it ?
Does Abandonned mechanism tells the advance stacktrace? that will be so
great.
Imagine : broker xxx, time-out 120 s, borrowed by --- stacktrace ---
I will try it tomorrow, thanks a lot. Armin.
Regards
On 4/25/06, Armin Waibel [EMAIL PROTECTED] wrote:
Bruno CROS wrote:
using proxies ?
Oh, i see now. Proxy opens and closes broker well. that's it ?
I didn't think to that. Tsss...
I'm sorry.
It seems that i'm looking for my lost brokers since too much time ago.
I guess i'm going to check all my DAOs and all my transactions again
(or
may
be someone else now ;-) )
You could extend or modify the PersistenceBrokerImpl instance and
override method
public void setClosed(boolean closed)
If set 'false' (PB instance was obtained from the pool) throw and catch
an exception to trace the current method caller.
Override method
protected void finalize()
If current broker instance is not closed print the stack trace from
setClosed-method.
Then it will be easy to find broker leaks. I will add a similar
behavior
till next release.
regards,
Armin
Thanks again.
Bye.
On 4/25/06, Armin Waibel [EMAIL PROTECTED] wrote:
Hi Bruno,
Bruno CROS wrote:
Hi Armin,
Here's is a schematic example :
Consider a service method that returns an object ProductBean.
ProductBean
is not O/R mapped but the reading calls a second method that read
O/R
mapped Product object. Then, relations are followed, to find
description
of
his Category (Consider that a product have 1 Category.
2nd method looks like that (classic):
public static Product getProduct(String id) {
PersistenceBroker broker = null;
try {
PersistenceBroker brojer =
PersistenceBrokerFactory.defaultPersistenceBroker();
Identity oid = broker.serviceIdentity().buildIdentity(
Product.class,
id);
Product product = (Product) broker.getObjectByIdentity (oid);
return product;
} finally {
if (broker !=null )
{ broker.close();
}
}
}
Frst method looks like that :
public static ProductBean getProductBean(String id)
{ Product p = getProduct(id); // 2nd method call
if (p!=null)
{ ProductBean product = new ProductBean();
product.setDescription(p.getDescription());
product.setID (p.getId());
// and here's the O/R recall
product.setCategoryDescription ( p.getCategory
Re: Procedure based sequencence generator repeating values
Hi! I'm still with this problem. Could someone say if SequenceManagers use default connection present at current thread? Or it's executed inside same transaction (I don't know if this implies same connection)? Thanks for any clarifications! Richter Edson Carlos Ericksson Richter escreveu: Armin Waibel escreveu: Hi, I'm not a database expert, so please forbear with me ;-) Edson Carlos Ericksson Richter wrote: Hi! There is a very long time since my last problem with OJB - thank you guys, it's awesome how good work was done until now. In last month, I was migrating from Oracle to MS SQL, and changed from Sequence Manager Oracle native to Procedure based on MS SQL. Worked great on tests, but when in production, sometimes procedure returns same value for two users, overriding content of child tables (it override child tables, then throw duplicate primary key exception for parent table but changes on child tables are not being rolled back). Are you sure that the changes written to database or could it be a caching problem? Well, independent of being a cache problem, I gettin records overwritten, what is bad per se. I'm sure I'm beginning and rollbacking transactions, and opening and closing connections (i never had this problem with Oracle, by example). Did you made concurrency tests against SequenceManagerStoredProcedureImpl? In OJB test-suite you can find a test case called SequenceManagerTest. This test case include concurrency sequence generation tests. Is the issue reproduceable via unit tests? No, I've made no tests... I tried community before (withou much luck, until now :D ) In SequenceManagerStoredProcedureImpl source code I can't find critical sections. So I assume it's a MSSQL concurrency problem. Does UPDATE OJB_NEXTVAL_SEQ... exclusive lock the table row? Well, I was supposing it is. But after reading SP4 fixlist for SQL2000, I start having doubts... So, I'll try to increase to REPETEABLE READ as default transaction level, and see what happens (god save our souls, because REPETEABLE READ almost always gives problems of deadlocking with SQL Server). I appreciate your comments, and I'll expect sequence gerenator author give some comments (I really appreciate if thats possible)... Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem joining two tables with same column name
Hi, Does anyone have the solution for this? Do mail to the following id [EMAIL PROTECTED] Thanks Neha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Procedure based sequencence generator repeating values
Ok, guys: now, I'm lost! I changed auto-commit from 1 to 2, and now, appear OJB is trying to insert records twice - on every new object I store, I get primary key violation! I'm using PB API with MsSQL Server 2000 SP4 and JDBC Driver for MS SQL Server 2005 latest release. Someone knows what is going on? Any tips, please!!! Richter Edson Carlos Ericksson Richter escreveu: Hi! I'm still with this problem. Could someone say if SequenceManagers use default connection present at current thread? Or it's executed inside same transaction (I don't know if this implies same connection)? Thanks for any clarifications! Richter Edson Carlos Ericksson Richter escreveu: Armin Waibel escreveu: Hi, I'm not a database expert, so please forbear with me ;-) Edson Carlos Ericksson Richter wrote: Hi! There is a very long time since my last problem with OJB - thank you guys, it's awesome how good work was done until now. In last month, I was migrating from Oracle to MS SQL, and changed from Sequence Manager Oracle native to Procedure based on MS SQL. Worked great on tests, but when in production, sometimes procedure returns same value for two users, overriding content of child tables (it override child tables, then throw duplicate primary key exception for parent table but changes on child tables are not being rolled back). Are you sure that the changes written to database or could it be a caching problem? Well, independent of being a cache problem, I gettin records overwritten, what is bad per se. I'm sure I'm beginning and rollbacking transactions, and opening and closing connections (i never had this problem with Oracle, by example). Did you made concurrency tests against SequenceManagerStoredProcedureImpl? In OJB test-suite you can find a test case called SequenceManagerTest. This test case include concurrency sequence generation tests. Is the issue reproduceable via unit tests? No, I've made no tests... I tried community before (withou much luck, until now :D ) In SequenceManagerStoredProcedureImpl source code I can't find critical sections. So I assume it's a MSSQL concurrency problem. Does UPDATE OJB_NEXTVAL_SEQ... exclusive lock the table row? Well, I was supposing it is. But after reading SP4 fixlist for SQL2000, I start having doubts... So, I'll try to increase to REPETEABLE READ as default transaction level, and see what happens (god save our souls, because REPETEABLE READ almost always gives problems of deadlocking with SQL Server). I appreciate your comments, and I'll expect sequence gerenator author give some comments (I really appreciate if thats possible)... Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: standalone getDefaultBroker auto-retrieve
Hi Armin,
The detection mechanism works, but i have a strange behaviour, i collected
some open-broker detections. So i had a look into code, and i saw my close
call in a finally clause. this is correct.
So, i don't doubt about java finally, but the implementation of my
closeBroker method. In fact, my close Broker is an implementation to close
broker if there is no transaction running on thread. When transaction is
detected, some methods methods use same broker than the transaction does,
this is to work with the objects handled by transaction. So when no
transaction, defautBroker is used, and closed at the end , in finally
clause.
So method does a broker.close() only if
getImplementation.getDatabase(...).getCurrentTransaction
is null (and broker is not null of course)
So, the question is : when currentTransaction is not null ( meaning that
broker will not be close by the method) whereas there is no open
transaction?
I do not have idea at all. I will have a lokk Tuesday.
Thanks for your help. Again.
On 4/28/06, Bruno CROS [EMAIL PROTECTED] wrote:
Yep. I did something like... with an immediate catched exception!! it
works...
I add a method into PersistenceBrokerFactory to artificially fire all the
finalize methods. This method call releaseAllInstances and System.gc().
then Finalize are all fired. It works well.
Will release 1.0.5 come out soon? I need the release with circular
references update.
else, is there a downloadable nightly build.
Thanks a lot.
Regards
On 4/28/06, Armin Waibel [EMAIL PROTECTED] wrote:
Hi Bruno,
below you can find #setClosed(...) and #finalize() of the modified PB
source (will check in this in a few days).
regards,
Armin
/**
* A stack trace of this broker user.
* Used when broker leak detection is enabled.
*/
protected String brokerStackTrace;
public void setClosed(boolean closed)
{
// When lookup the PB instance from pool method setClosed(false)
// was called before returning instance from pool, in this case
// OJB have to refresh the instance.
if(!closed)
{
refresh();
// configurable boolean
if(brokerLeakDetection)
{
brokerStackTrace = ExceptionUtils.getFullStackTrace(
new Exception(PersistenceBroker caller stack));
}
}
this.isClosed = closed;
}
protected void finalize()
{
try
{
super.finalize();
// if not closed == broker leak detected
if (!isClosed)
{
String msg = Garbage collection: Unclosed
PersistenceBroker instance detected, check code for PB leaks.;
if(brokerLeakDetection)
{
logger.error(msg + Broker caller stack is:
+ SystemUtils.LINE_SEPARATOR + brokerStackTrace);
}
else
{
logger.warn(msg);
}
close();
}
}
catch(Throwable ignore)
{
// ignore
}
}
Bruno CROS wrote:
Hi Armin, thanks for solution , but i'm not sure i did get it all !!
Can you confirm solution?
Well, i understand i have to override setCLosed method to catch when
broker
open (is borrowed), throw an exception to save a stacktrace with a
catch.
So , PB remembers his last loan. that's it ?
When finalize is done (that means application is ended ?), if broker
is not
closed (how does i known that ?), i have to retrieve the last stored
loan
stacktrace, log it and (why not) throw an BrokerNotClosedException.
That's
it ?
Does Abandonned mechanism tells the advance stacktrace? that will be
so
great.
Imagine : broker xxx, time-out 120 s, borrowed by --- stacktrace ---
I will try it tomorrow, thanks a lot. Armin.
Regards
On 4/25/06, Armin Waibel [EMAIL PROTECTED] wrote:
Bruno CROS wrote:
using proxies ?
Oh, i see now. Proxy opens and closes broker well. that's it ?
I didn't think to that. Tsss...
I'm sorry.
It seems that i'm looking for my lost brokers since too much time
ago.
I guess i'm going to check all my DAOs and all my transactions again
(or
may
be someone else now ;-) )
You could extend or modify the PersistenceBrokerImpl instance and
override method
public void setClosed(boolean closed)
If set 'false' (PB instance was obtained from the pool) throw and
catch
an exception to trace the current method caller.
Override method
protected void finalize()
If current broker instance is not closed print the stack trace from
setClosed-method.
Then it will be easy to find broker leaks. I will add a similar
behavior
till next release.
regards,
Armin
Thanks again.
Bye.
On 4/25/06, Armin Waibel [EMAIL PROTECTED] wrote:
Hi Bruno,
Re: Procedure based sequencence generator repeating values (MAYBE SOLVED)
Ok, guys. I think I discovered a piece of solution for this problem: 1) Database must be in Full recovery model 2) Every trigger must start with SET NOCOUNT ON and end with SET NOCOUNT OFF 3) The OBJ_NEXTVAL_PROC should start with SET NOCOUNT OFF We are in testing fase right now, but appear the problem is solved. Thanks for tips (special do Armin, who was unique to respond :( ). I'll let you know (during next week) if this really solved. If so, I'll ask to add this notes to documentation, to avoid hours of reserach to others in future. Best regards, Edson Richter Edson Carlos Ericksson Richter escreveu: Ok, guys: now, I'm lost! I changed auto-commit from 1 to 2, and now, appear OJB is trying to insert records twice - on every new object I store, I get primary key violation! I'm using PB API with MsSQL Server 2000 SP4 and JDBC Driver for MS SQL Server 2005 latest release. Someone knows what is going on? Any tips, please!!! Richter Edson Carlos Ericksson Richter escreveu: Hi! I'm still with this problem. Could someone say if SequenceManagers use default connection present at current thread? Or it's executed inside same transaction (I don't know if this implies same connection)? Thanks for any clarifications! Richter Edson Carlos Ericksson Richter escreveu: Armin Waibel escreveu: Hi, I'm not a database expert, so please forbear with me ;-) Edson Carlos Ericksson Richter wrote: Hi! There is a very long time since my last problem with OJB - thank you guys, it's awesome how good work was done until now. In last month, I was migrating from Oracle to MS SQL, and changed from Sequence Manager Oracle native to Procedure based on MS SQL. Worked great on tests, but when in production, sometimes procedure returns same value for two users, overriding content of child tables (it override child tables, then throw duplicate primary key exception for parent table but changes on child tables are not being rolled back). Are you sure that the changes written to database or could it be a caching problem? Well, independent of being a cache problem, I gettin records overwritten, what is bad per se. I'm sure I'm beginning and rollbacking transactions, and opening and closing connections (i never had this problem with Oracle, by example). Did you made concurrency tests against SequenceManagerStoredProcedureImpl? In OJB test-suite you can find a test case called SequenceManagerTest. This test case include concurrency sequence generation tests. Is the issue reproduceable via unit tests? No, I've made no tests... I tried community before (withou much luck, until now :D ) In SequenceManagerStoredProcedureImpl source code I can't find critical sections. So I assume it's a MSSQL concurrency problem. Does UPDATE OJB_NEXTVAL_SEQ... exclusive lock the table row? Well, I was supposing it is. But after reading SP4 fixlist for SQL2000, I start having doubts... So, I'll try to increase to REPETEABLE READ as default transaction level, and see what happens (god save our souls, because REPETEABLE READ almost always gives problems of deadlocking with SQL Server). I appreciate your comments, and I'll expect sequence gerenator author give some comments (I really appreciate if thats possible)... Thanks, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Returning DynaBeans
hi phil, we could return DynaBeans for ReportQueries instead of Object[]. i'm not sure if DynaBeans are useful for normal queries. jakob Armin Waibel wrote: Hi Phil, [EMAIL PROTECTED] wrote: I am interested in finding out more information about OJB's support of the commons-beanutils package. Is it possible to configure OJB to return instances of DynaBeans instead of instances of POJOs? This is (currently) not possible. This would greatly reduce the amount of code required to support our persistence layer ... basically it would be reduced to ojb class descriptors for each object. The persistence broker operations getObjectByQuery for example would need to know what type of object I am searching for (so it can look up the appropriate class descriptor), but then it would return a DynaBean holding the marshalled object. Is this possible? It would remove nearly all of my redundant persistence layer code! Sorry I never used DynaBeans. But I think this will not be trivial. Could you give me hint how OJB should return DynaBeans instead of mapped persistence capable objects? regards, Armin Thanks, Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
