Re: Design question with Struts
Hi Brian, On Thu, 23 Oct 2003 20:51:21 -0400, [EMAIL PROTECTED] wrote: > (snipped) > >1) A Cache implementation that only provides java object identity ( = ) >within a single transaction boundary. I am not sure how this would work, may >have to hack around some. Cache might clone the object and return the clone >within transactional boundaries, but I am not sure the cache can detect >transactions. Maybe use cglib to return a derived proxy that handles things. >Hmmm. Must go poke when I have a chance. Isn't that what ObjectCachePerBrokerImpl does? I believe it clears the cache whenever a PB instance is closed, which happens when a transaction (ODMG at least) is committed or aborted. I was also thinking of relying on this to safely pass domain object out to clients. Cheers, Gerhard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT]RE: Design question with Struts
Quoting Shane Mingins <[EMAIL PROTECTED]>: > ... have been reading Core J2EE Patterns and Patterns of Enterprise > Application Architecture. > btw - if you find those books useful I must highly reccomend _Domain- Drive_Design_ by Eric Evans. It is another annoying-expensive hardback design books but it *really* looks at domain design hard and is quite solid. Core J2EE and PEAA sort of mention domain models as good things but never go into building a good one. They both focus a great deal on layer-interface issues (which are big issues) compared to model design, which is the core of any good application. Anyway, will hush up now as I don't get commissions =) -Brian - This mail sent through IMP: http://horde.org/imp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design question with Struts
Quoting Shane Mingins <[EMAIL PROTECTED]>:
>
> Yes it does :-) And answered more. Thanks. I am currently developing a
> Struts/OJB app and have not yet nutted out the architectural issues/design
> ... have been reading Core J2EE Patterns and Patterns of Enterprise
> Application Architecture.
>
> OJB caches a read object so that I do not wish to pass that actual
instance
> up to the View layer for editing IOW that instance only changes when
an
> updated version is persisted. So in essence I need to create a session
> copy of my domain model from its persisted state to be available for
editing
> (business transactions). But as this is a object with a collection of
other
> editable objects it seems that creating a type of Value Object or session
> copy is not that trivial.
What I do is retrieve a fresh version of the object with each command. A
typical Command begins like:
public static Map execute() throws CommandException
{
if (!validate()) return this.errors; // validate populates errors
try
{
Unit unit = BaseRepository.beginUnit();
User user = UserRepository.findById(this.getUserId(), unit);
User friend = UserRepository.findById(this.getFriendId(), unit);
Request request = user.requestFriend(friend);
unit.commit()
catch (PersistenceException e)
{
throw new CommandError("Unable to request friend: " +
e.getMessage(), e);
}
Map results = new HashMap();
if (request == null)
{
this.errors = new ArrayList();
this.errors.add(this.UNKNOWN_ERROR);
}
else
{
results.put(this.REQUEST, request);
}
results.put(this.USER, user);
results.put(this.FRIEND, friend);
return results;
}
The Unit provides a transaction wrapper, the *Repository classes provide
querying. They can do OQL, but the byId(...) type query is optimized to hit
the cache by creating an ObjectIdentity and querying by identity, so it is
preferred.
Once the object is outside of the Transaction changes you make to it are not
propogated down to the database. In my particular case (well not for my toy
app, but for the larger app the toy is a spike for) anyway. I need to check
what happens to the cached version if you make changes on the non-
transactional persistent object. As I *don't* anywhere it isn't a problem
for me, but I am not confident of the behavior of the cache for non-
transactional versions. Am thinking of two solutions
1) A Cache implementation that only provides java object identity ( = )
within a single transaction boundary. I am not sure how this would work, may
have to hack around some. Cache might clone the object and return the clone
within transactional boundaries, but I am not sure the cache can detect
transactions. Maybe use cglib to return a derived proxy that handles things.
Hmmm. Must go poke when I have a chance.
2) Changing my code generator to go back to an old idea of generating a
getter-only interface for the data containers. I generate a base impl of
each persistent class with just the persistent fields and derive from it for
all logical stuff. This makes for handy-dandy transfer objects, etc. Back
when I started thinking about it i considered generating the base impl, a
getter, and a getter/setter interface specifically for this. i didn't wind
up going with it as I decided that was just overkill, I trust the developers
I work with. Cache behaviour could be an issue though. Must go write some
learning tests.
Anyway...
A side effect is that I can plug ODMG, OTM, and other (am thinking of doing
a Hibernate implementation for shits and giggles -- it claims to support OQL
as a subset of HQL so all my query string should still work as-is)
persistence mechanisms very easily. Right now I swap out ODMG and OTM
regularly as I am using this project to get familiar with the OTM.
-Brian
-
This mail sent through IMP: http://horde.org/imp/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mapping problem or something VERY wierd...
The mapping needed the obvious primary key
On Thu, 2003-10-23 at 17:15, Andy Czerwonka wrote:
> In looking at the SQL, and update is done when I do the store.. hey I
> think the PK is NOT unique... yup - it's not unique... that's gotta be
> the problem...
>
> On Thu, 2003-10-23 at 16:07, Andy Czerwonka wrote:
> > I've got a simple 1..n association and I'm doing something like
> > this...(pardon the syntax... just trying to make a point)
> >
> > Parent parent = new Parent()
> > Child c1 = new Child(parent);
> > Child c2 = new Child(parent);
> > parent.getChildren.add(c1);
> > parent.getChildren.add(c2);
> > broker.store(parent);
> > broker.commit();
> >
> > database looks good... 1 record in the parent table and 2 in the child
> > table with fk point back to the parent record...looks like:
> >
> > parent
> > +--c1
> > +--c2
> >
> >
> > and then all hell breaks loose...
> >
> > Parent found = broker.query(parent);
> >
> > so far, so good, looks like it came from the cache... all references
> > look good, still have:
> >
> > parent
> > +--c1
> > +--c2
> >
> > checked the database.. all good..
> >
> > parent.setAnotherAttribute("changed state of parent");
> > broker.store(parent);
> >
> > still all good.. checked the database...
> >
> > and NOW
> >
> > broker.commit();
> >
> > look in the database, and I see:
> >
> > parent
> > +--c2
> > +--c2
> >
> > HHHEEELLLPPP
> > No Idea.
> >
> > -andy
> >
> >
> > -
> > 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: mapping problem or something VERY wierd...
In looking at the SQL, and update is done when I do the store.. hey I
think the PK is NOT unique... yup - it's not unique... that's gotta be
the problem...
On Thu, 2003-10-23 at 16:07, Andy Czerwonka wrote:
> I've got a simple 1..n association and I'm doing something like
> this...(pardon the syntax... just trying to make a point)
>
> Parent parent = new Parent()
> Child c1 = new Child(parent);
> Child c2 = new Child(parent);
> parent.getChildren.add(c1);
> parent.getChildren.add(c2);
> broker.store(parent);
> broker.commit();
>
> database looks good... 1 record in the parent table and 2 in the child
> table with fk point back to the parent record...looks like:
>
> parent
> +--c1
> +--c2
>
>
> and then all hell breaks loose...
>
> Parent found = broker.query(parent);
>
> so far, so good, looks like it came from the cache... all references
> look good, still have:
>
> parent
> +--c1
> +--c2
>
> checked the database.. all good..
>
> parent.setAnotherAttribute("changed state of parent");
> broker.store(parent);
>
> still all good.. checked the database...
>
> and NOW
>
> broker.commit();
>
> look in the database, and I see:
>
> parent
> +--c2
> +--c2
>
> HHHEEELLLPPP
> No Idea.
>
> -andy
>
>
> -
> 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: Design question with Struts
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, 24 October 2003 11:45 a.m. > To: [EMAIL PROTECTED] > Subject: Re: Design question with Struts > > Shane, > > In this particular application, yes that is exactly what it does. I don't > need any modifications that span multiple requests in this particular app. > > This type of system doesn't work for everything, but it does for a lot I > have found. Large scale GIS systems I am pretty confident it wouldn't work > well in, for instance. > > Does that clear up what I described? > Yes it does :-) And answered more. Thanks. I am currently developing a Struts/OJB app and have not yet nutted out the architectural issues/design ... have been reading Core J2EE Patterns and Patterns of Enterprise Application Architecture. OJB caches a read object so that I do not wish to pass that actual instance up to the View layer for editing IOW that instance only changes when an updated version is persisted. So in essence I need to create a session copy of my domain model from its persisted state to be available for editing (business transactions). But as this is a object with a collection of other editable objects it seems that creating a type of Value Object or session copy is not that trivial. Cheers Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question with Struts
Shane, In this particular application, yes that is exactly what it does. I don't need any modifications that span multiple requests in this particular app. The client application (ie, the web application) isn't allowed to hold onto "live" domain objects. If need be it can hold onto a transaction with a series of modifications, but then you wind up holding a lot of transactional state around in some type of session (be it a stateful session bean, http session, etc). I have modified domain objects that are not yet persisted all the time - right before they are persisted =) Some of the commands are pretty complex (despite it being a simple application -- it does some fun stuff trying to model human/group relations that has not yet been exposed to the UI) and build quite a bit of domain information before persisting any of it. Right now commands in that particular application are all atomic, however. If I needed to have a long-lived transaction in this application (ie, create and modify a domain object via multiple hits) I would probably design it around capturing the changes in an OTM Transaction and giving the client a transaction token in order to associate the new changes with the previous transaction) -- the domain model is still only "live" within the core application upon which the other apps are just clients with some interface to twiddle it. This type of system doesn't work for everything, but it does for a lot I have found. Large scale GIS systems I am pretty confident it wouldn't work well in, for instance. Does that clear up what I described? -Brian ps: sorry for not quoting, I am at NFJS Atlanta and working through a pita webmail client - This mail sent through IMP: http://horde.org/imp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Order by across extents and question about materialization
was this ever implemented? I'm having the same issue with sorting extents
in RC3.
"Matthew Baird" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
my thoughts are we could generate a comparator on the fly and use it to sort
the collection, it would definitely be done in the code, not in the db,
that's why it would only work for getby collection and not getby iterator.
we would store the field they wanted to sort on and use that reflectively to
sort like this:
Collections.sort(this, new ReflectiveComparator()
{
public int compare (Object o1, Object o2)
{
// do all the stuff to get the method reflectively on both the objects
return
(o1ReflectiveMethodReturnValue.compareTo(o2ReflectiveMethodReturnValue);
}
}
);
obviously there is a little bit more to it than that, since this will only
work for types that have Compare implemented, but it could be made to work
for all types where it makes sense, since it has to follow the rules of db
sorting.
anyway, this would just be a convenience for the user as they could easily
write the sort code themselves.
m
-Original Message-
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 23, 2003 8:50 AM
To: OJB Users List
Subject: Re: Order by across extents and question about materialization
hi matthew,
who would do the sorting for getCollectionByQuery ? imo this has to be
done in the code not in the db.
jakob
Matthew Baird wrote:
>I've put some thought into the sorting across extent problem, and while I
think it's solvable pretty easily for a getCollectionByQuery, it's not as
easy to solve in a getIteratoryByQuery situation.
>
>I think it would be confusing to present two different behaviours.
>
>order by on extents mapped to the same table will work, however.
>
>-Original Message-
>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, January 22, 2003 11:14 AM
>To: OJB Users List
>Subject: Re: Order by across extents and question about materialization
>
>
>hi chris,
>
>you're right extents are handled by separate queries (one sql for each
>concrete extent) so sorting is a problem here.
>the second problem can easily be solved by using the
>PersistentFieldPropertyImpl instead of the default. see
>PersistentFieldClass= in ojb.properties.
>
>hth
>jakob
>
>Chris Rossi wrote:
>
>
>
>>Part I: The use of 'order by' with collections containing members of
>>differing type.
>>
>>Howdy, I've noticed the following. Let's say we have a class
>>structure that looks kind of like this:
>>
>>> class="Mamma">
>>> name="children"
>> element-class="Child"
>> orderby="index"
>> sort="ASC"
>> >
>>
>>
>>
>>
>>> class="Child">
>>
>>
>>
>>
>>> class="BoyChild">
>>
>>
>>> class="GirlChild">
>>
>>
>>For brevity I've left out fields in above, but assume all objects have
>>an 'id' feild and all Child objects also have 'parentId' and 'index'
>>field. Where 'index' is used to maintain an ordering on a collection
>>of Children.
>>
>>What I've found is that when the Children are a mix of types, ie mix
>>of BoyChildren and GirlChildren OJB fails to order them correctly.
>>Instead of the entire group being sorted by index, what you get back
>>is all of the boys in the group followed by all of the girls. I
>>assume this is because under the hood the 'order by' is being used in
>>the two seperate SQL queries to get children but it hadn't occurred to
>>anyone yet that it would be necessary to do sorting on the larger
>>collection in the event that a collection contains objects of
>>different types and residing in different tables.
>>
>>Part II: Materialization question related to above
>>
>>While using OJB 0.9.7 I had worked around the problem above by adding
>>a sort to the setter method on a collection. ie:
>>
>>public class Mamma {
>> public void setChildren( List children ) {
>>this.children = new ArrayList( children );
>>sortByIndex( children );
>> }
>>}
>>
>>Now that I'm in the middle of an upgrade to 0.9.9.1 I'm finding that
>>my workaround no longer works. For testing purposes I've changed the
>>above to:
>>
>>public class Mamma {
>> public void setChildren( List children ) {
>>throw new RuntimeException( "Am I being called?" );
>>/*this.children = new ArrayList( children );
>>sortByIndex( children );*/
>> }
>>}
>>
>>What I've discovered is that the setChildren() method is not being
>>called. And yet the object materialized by OJB contains children.
>>I'm kind of stumped as to how this can be occuring. What is the magic
>>that is causing this to happen? Are any setter methods for
>>collections being called during materialization? For that matter are
>>setter methods for fields being called during materialization? And if
>>no for either, how is an object materialized then?
>>
>>chris rossi
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
>>For additional commands, e-mail:
>>
>>
>>
>>
>>
>
>
>--
mapping problem or something VERY wierd...
I've got a simple 1..n association and I'm doing something like
this...(pardon the syntax... just trying to make a point)
Parent parent = new Parent()
Child c1 = new Child(parent);
Child c2 = new Child(parent);
parent.getChildren.add(c1);
parent.getChildren.add(c2);
broker.store(parent);
broker.commit();
database looks good... 1 record in the parent table and 2 in the child
table with fk point back to the parent record...looks like:
parent
+--c1
+--c2
and then all hell breaks loose...
Parent found = broker.query(parent);
so far, so good, looks like it came from the cache... all references
look good, still have:
parent
+--c1
+--c2
checked the database.. all good..
parent.setAnotherAttribute("changed state of parent");
broker.store(parent);
still all good.. checked the database...
and NOW
broker.commit();
look in the database, and I see:
parent
+--c2
+--c2
HHHEEELLLPPP
No Idea.
-andy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design question with Struts
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, 24 October 2003 10:54 a.m. > To: [EMAIL PROTECTED] > Subject: Re: Design question with Struts > > The Command is designed so that any object in the domain model that it > modifies is populated into the response as a transfer object (really it is > the domain object, but once it is outside transaction context of OJB it is > no longer "live" so is safe to pass back to clients). These are used by > Struts to render stuff. Hi Brian Can I check if I correctly understand what you have said here ... you would never have a modified domain object that has yet to be persisted? IOW your command modifies and persists the domain object in one hit?? Before I ask or comment more I will wait to see if I understand you correctly ;-) Saves typing and misunderstanding (I hope *grin*) Cheers Shane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Design question with Struts
I just did an OJB+Struts app. I have a Command interface (not java interface, layer type interface) top model object which knows about the persistence mechanism. Individual commands are *not* dependent upon struts at all, but happen to have properties populated that match nicely to the FormBean defn's. Commands know about OJB and the domain object model. They provide a means to manipulate the object model. Struts Actions have access to the command interface via a factory (the particular factory I use is designed to hide whether the Command is a local or remote EJb SessionBean, but it works just as well for POJO's - in fact it was originally designed around POJO commands). The Action gets an instance of a command object, and populates properties onto it, the executes it. The Command is designed so that any object in the domain model that it modifies is populated into the response as a transfer object (really it is the domain object, but once it is outside transaction context of OJB it is no longer "live" so is safe to pass back to clients). These are used by Struts to render stuff. A typical Action merely grabs a Command, populates it, executes it, pulls values from the Results object and populates them into the Request or Session depending on how it is configured. i don't have it down to a declarative implementation yet (ie, i have to customize each Action) but I am completely sure I can refactor it down to a single Action implementation and a config file when i have time. I have had a fair bit of success with this ( http://gifts.skife.org ) and it is basically my play-with-new-ideas project so am more than happy to share the source if you want to contact me privately about it. -Brian - This mail sent through IMP: http://horde.org/imp/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Access PersistenceBroker from FieldConversion API?
Hello All, I am developing OJB FieldConversion for Oracle SDO data structures. What I need is access to current JDBC Connection from FieldConversion's javaToSql() / sqlToJava() methods. Unfortunately FieldConversion API does not provide any context information (like current PersistenceBroker instance). Is there any trick that can help me to get current PersistenceBroker in context of FieldConversion ? (I would hate to define my own PersistenceBrokerFactory that maintains Thread-to-PersistenceBroker weak hash map.) Thanks, Andy
Re: does QueryBySQL work?
hi cristopher, yes, this is supported. the result of a this query are business-objects, so all necessary columns must be included in the select. hth jakob Christopher Tava wrote: Dear OJB user group, Is QueryBySQL supported? if so, are there any limitations? thank you, chris - Do you Yahoo!? The New Yahoo! Shopping - with improved product search - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: help for init problem
Yep. The order of operations is: - call the no-arg constructor - populate the member fields - call the initialization method - populate the references I typically use a lazy intitialization pattern where the first time the reference is requested I do any initialization required. -Original Message- From: Hal Arnold [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 7:29 PM To: [EMAIL PROTECTED] Subject: help for init problem Folks, I have an object; Advertiser that has an object; Account. The advertiser also has an AdvertiserState object (created on the fly, not in storage) that represents the status of the advertiser/account combo (the account actually holds the currentStatus as a string, for persistance. I'm using the persistanceBroker version of OJB. I'd like to 'initialize' the advertiser with it's correct AdvertiserState on creation of the advertiser-account object. I note that pb has a class-descriptor attribute: initialization-method: . . . ... etc /> that can get called on creation. My problem is that the account is created seemingly after the advertisement, and the whole object is then assembled. Which means that the account, which has the persistent value of the current object status can't be known when I want it (when the advertiser's init method would get called) to create my on-the-fly AdvertiserState association. Anybody have an idea how I might solve this delemma? Some sort of lazy instatiation? I'm working around it at present, by creating the whole association and then programmatically calling an initialization() routine on the created advertiser. cheers, hba - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Design question with Struts
I would recommend creating a services layer for your business logic. With this pattern, your Actions would simply call your services. Your services will contain your business logic. You could still have factories to create the bean's but rather than keeping that logic in the factory, I would move it to the service. just my 2 cents. -alexander You wrote: > Hi, > I am using OJB in a struts Web application. I am trying to separate the > business Logic from the controler. > My question is : is it a good design to make a Factory for each bean and in > the actions call only methods on the factories ? > Regards, > Yassine > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- -alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Design question with Struts
Hi, I am using OJB in a struts Web application. I am trying to separate the business Logic from the controler. My question is : is it a good design to make a Factory for each bean and in the actions call only methods on the factories ? Regards, Yassine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inner class as persistent. Is it possible?
Hi, (don't know if I understand your question) no problem. Many junit tests use static inner persistence cabable classes. ... PersistentA is a static inner class of ComplexMultiMapped class. Or don you mean nested objects? http://db.apache.org/ojb/tutorial3.html#nested objects regards, Armin [EMAIL PROTECTED] wrote: Hi all, When i use LiDO CE (JDO implementation), some of my persistent classes was implemented as inner. Can I use this approach with OJB? Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inner class as persistent. Is it possible?
Hi all, When i use LiDO CE (JDO implementation), some of my persistent classes was implemented as inner. Can I use this approach with OJB? Thanks.
RE: problems with batch-mode=true
Okay, first of all, thanks for the fix Mark. Now that I have it
working, can anyone explain why my performance just dropped about 20%
after turning on batch mode? I reason I wanted a fix is because i was
trying to get some better performance, not worsen then performance!
HELP!!!
On Thu, 2003-10-23 at 03:31, Mark Rowell wrote:
> Hi
>
>
>
> Sorry for the flurry of emails but changing == to .equals in the doExecute
> method of
> PreparedStatementInvocationHandler fixes this problem.
>
> Change line 214 in RC4 from
>
> if ( ((Method)_methods.get(i)) ==
> ADD_BATCH )
> {
> /**
>* we invoke on the platform
> and pass the stmt as an arg.
>*/
> ((Method)
> _methods.get(i)).invoke(m_platform, new Object[] {stmt});
> }
> else
> {
> ((Method)
> _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
> }
>
>
> if ( ADD_BATCH.equals(
> _methods.get(i)) )
> {
> /**
>* we invoke on the platform
> and pass the stmt as an arg.
>*/
> ((Method)
> _methods.get(i)).invoke(m_platform, new Object[] {stmt});
> }
> else
> {
> ((Method)
> _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
> }
>
> BTW the cast in the equality is unecessary.
>
> Regards
>
> Mark Rowell
>
> -Original Message-
> From: Mark Rowell [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 10:27
> To: 'OJB Users List'
> Subject: RE: problems with batch-mode=true
>
>
> Hi
>
> As a follow on I checked the source for java.lang.reflect.Method and it has
> an implementation Of equals which could possibly indicate tat the equality
> operator (==) does not hold for methods.
>
> Mark
>
> -Original Message-
> From: Mark Rowell [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 10:23
> To: 'OJB Users List'
> Subject: RE: problems with batch-mode=true
>
>
> Hi
>
> Regarding this issue it looks like (at least as far as RC4 is concerned)
> that in the doExecute method of PreparedStatementInvocationHandler.java the
> following line (223) gets invoked
>
> ((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
>
> In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
> similar error to Bonnie (java.lang.IllegalArgumentException: object is not
> an instance of declaring class)
>
> The methods returned by _methods.get(i) is
>
> public void
> org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
> edStatement)
>
> And we are trying to executed it on the statement rather than passing the
> platform instance. I think the problem Is in the if statement in that it
> does an == rather than a .equals() call to determine whether we want to call
> the addBatch method. Now, I do not know whether within a single JVM that the
> following Returns true
>
> Method method1 = obj.getClass().getMethod("methodName", ); Method
> method2 = obj.getClass().getMethod("methodName", ); method1 ==
> method2; // is this gurantee dto be true like it is for instances of Class
> e.g.
>
> Obj.getClass() == Obj.getClass() is guranteed to be true?
>
> Regards,
>
> Mark Rowell
>
>
> -Original Message-
> From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2003 14:02
> To: OJB Users List
> Subject: RE: problems with batch-mode=true
>
>
> Hi,
> Here is the code that I tested. You can
> see that setBatchMode is called before I start
> the tx.
> try
> {
> broker.serviceConnectionManager().setBatchMode(true);
> broker.beginTransaction();
> for (int i = 0; i < 100; i++)
> {
> CustomerInterface customer = new Customer();
> customer.setCustomerNumber("100" + i);
> customer.setFirstName("Big");
> customer.setLastName("Customer");
> customer.setCustomerName("BadCorporation");
> customer.setDeleteTag(Boolean.FALSE);
> broker.store(customer);
> }
> // conMan.executeBatch();
> broker.commitTransaction();
> }
> catch(Exception e)
>
Re: RE : problems with batch-mode=true
See Mark Rowell's posts to see the bug and fix.
Thanks to Mark!!
Cheers!!
On Thu, 2003-10-23 at 06:53, Emmanuel Dupont wrote:
> Please to tell you yhat we are three !
>
> :)
>
> -Message d'origine-
> De : Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Envoyé : jeudi 23 octobre 2003 14:33
> À : 'Mark Rowell '; ''OJB Users List' '
> Objet : RE: problems with batch-mode=true
>
> I have the same problem! I thought I was
> the only one.
>
> Bonnie MacKellar
>
> -Original Message-
> From: Mark Rowell
> To: 'OJB Users List'
> Sent: 10/23/03 7:59 AM
> Subject: RE: problems with batch-mode=true
>
> Armin
>
> No because I am not allowed to use CVS where I work..hence...
>
> Oh well!
>
> Thanks
>
> Mark
>
> -Original Message-
> From: Armin Waibel [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 11:37
> To: OJB Users List
> Subject: Re: problems with batch-mode=true
>
>
> Hi Mark,
>
> did you tried latest version from CVS?
> I think your mentioned bug was fixed in
> CVS.
>
> See
> http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/
> util
> /batch/PreparedStatementInvocationHandler.java
>
> regards,
> Armin
>
> Mark Rowell wrote:
> > Hi
> >
> > As a follow on I checked the source for java.lang.reflect.Method and
> > it has an implementation Of equals which could possibly indicate tat
> > the equality operator (==) does not hold for methods.
> >
> > Mark
> >
> > -Original Message-
> > From: Mark Rowell [mailto:[EMAIL PROTECTED]
> > Sent: 23 October 2003 10:23
> > To: 'OJB Users List'
> > Subject: RE: problems with batch-mode=true
> >
> >
> > Hi
> >
> > Regarding this issue it looks like (at least as far as RC4 is
> > concerned) that in the doExecute method of
> > PreparedStatementInvocationHandler.java the following line (223) gets
> > invoked
> >
> > ((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
> >
> > In my case when using batched mode, and JSQLConnect on MSSqlServer I
> > get a similar error to Bonnie (java.lang.IllegalArgumentException:
> > object is not an instance of declaring class)
> >
> > The methods returned by _methods.get(i) is
> >
> > public void
> > org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.
> > Prepar
> > edStatement)
> >
> > And we are trying to executed it on the statement rather than passing
> > the platform instance. I think the problem Is in the if statement in
> > that it does an == rather than a .equals() call to determine whether
> > we want to call the addBatch method. Now, I do not know whether within
>
> > a single JVM that the following Returns true
> >
> > Method method1 = obj.getClass().getMethod("methodName", );
> > Method method2 = obj.getClass().getMethod("methodName", );
> > method1 == method2; // is this gurantee dto be true like it is for
> > instances of Class e.g.
> >
> > Obj.getClass() == Obj.getClass() is guranteed to be true?
> >
> > Regards,
> >
> > Mark Rowell
> >
> >
> > -Original Message-
> > From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> > Sent: 22 October 2003 14:02
> > To: OJB Users List
> > Subject: RE: problems with batch-mode=true
> >
> >
> > Hi,
> > Here is the code that I tested. You can
> > see that setBatchMode is called before I start
> > the tx.
> > try
> > {
> > broker.serviceConnectionManager().setBatchMode(true);
> > broker.beginTransaction();
> > for (int i = 0; i < 100; i++)
> > {
> > CustomerInterface customer = new Customer();
> > customer.setCustomerNumber("100" + i);
> > customer.setFirstName("Big");
> > customer.setLastName("Customer");
> > customer.setCustomerName("BadCorporation");
> > customer.setDeleteTag(Boolean.FALSE);
> > broker.store(customer);
> > }
> > // conMan.executeBatch();
> > broker.commitTransaction();
> > }
> > catch(Exception e)
> > {
> > e.printStackTrace();
> > logger.error(e.getMessage());
> > broker.abortTransaction();
> > }
> > finally
> > {
> > broker.close();
> > }
> >
> > This chunk of code, exectued with batch-mode="true"
> > in repository_database.xml, results in the following
> > two exceptions :
> > java.lang.IllegalArgumentException: object is not an instance of
> declaring
> > class
> > at java.lang.reflect.Method.invoke(Native Method)
> > at
> >
> org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doEx
> ecut
> > e(Unknown Source)
> > at
> >
> org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invo
> ke(U
> > nknown Source)
> > at $Proxy0.doExecute(Unknown Source)
> > at
> > org.apache.ojb.broker.util.batch.Bat
RE: refresh=true OR refresh=false
Yes - if you can guarantee that B.setA(A) can't be invoked without a.getBs().add(B). Our app can't - or rather, it could, but then we couldn't deal with B's without dealing with As... Cheers, Charles. > -Original Message- > From: Andy Czerwonka [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 13:47 > To: OJB Users List > Subject: RE: refresh=true OR refresh=false > > > Thank you. I supposed, from a performance perspective, if the > relationship is ternary, I should have a convenience method that does > the setA(A) and A.getBs().add(B) and then I can turn it off > to stop the > SQL from being executed. Correct? > > On Thu, 2003-10-23 at 00:32, Charles Anthony wrote: > > Hi, > > It is indeed to do with caching. > > > > Let us have a one-to-many relation : A has many Bs. > > We modify A (but leave it's related B's alone), and A > remains in the cache. > > We then create a B, and associate it with A (e.g. b.setA(A) > ) - but we > > *don't* add it to A's collection of B's. > > If we then retrieve A from the Cache as a result of another query. > > If refresh = false, then the collection of B's will *not* > contain our new B. > > If refresh = true, the the collecton will contain the new B > - in other words > > the collection is refreshed when the object is retrieved > from the cache. > > > > The use of CollectionProxies prevents the actual > materialization of all > > object in colleciton until needed i.e. the full query is > not actually > > executed until the contents of the collection is accessed. > > > > Cheers, > > > > Charles. > > > > > -Original Message- > > > From: Andy Czerwonka [mailto:[EMAIL PROTECTED] > > > Sent: 22 October 2003 23:53 > > > To: OJB Users List > > > Subject: refresh=true OR refresh=false > > > > > > > > > In looking at the documentation, there isn't really anything > > > descriptive > > > regarding this attribute on collections/references. I'd like > > > to turn it > > > off, but I'm afraid. Should I be? Can someone help me > > > understand this > > > a little better so that I know what's going on? Is this a > > > cache thing? > > > > > > -andy > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > This email and any attachments are strictly confidential > and are intended > > solely for the addressee. If you are not the intended > recipient you must > > not disclose, forward, copy or take any action in reliance > on this message > > or its attachments. If you have received this email in > error please notify > > the sender as soon as possible and delete it from your > computer systems. > > Any views or opinions presented are solely those of the > author and do not > > necessarily reflect those of HPD Software Limited or its affiliates. > > > > At present the integrity of email across the internet > cannot be guaranteed > > and messages sent via this medium are potentially at risk. > All liability > > is excluded to the extent permitted by law for any claims > arising as a re- > > sult of the use of this medium to transmit information by or to > > HPD Software Limited or its affiliates. > > > > > > > > > - > > 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] > > This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : problems with batch-mode=true
Please to tell you yhat we are three !
:)
-Message d'origine-
De : Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Envoyé : jeudi 23 octobre 2003 14:33
À : 'Mark Rowell '; ''OJB Users List' '
Objet : RE: problems with batch-mode=true
I have the same problem! I thought I was
the only one.
Bonnie MacKellar
-Original Message-
From: Mark Rowell
To: 'OJB Users List'
Sent: 10/23/03 7:59 AM
Subject: RE: problems with batch-mode=true
Armin
No because I am not allowed to use CVS where I work..hence...
Oh well!
Thanks
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 11:37
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi Mark,
did you tried latest version from CVS?
I think your mentioned bug was fixed in
CVS.
See
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/
util
/batch/PreparedStatementInvocationHandler.java
regards,
Armin
Mark Rowell wrote:
> Hi
>
> As a follow on I checked the source for java.lang.reflect.Method and
> it has an implementation Of equals which could possibly indicate tat
> the equality operator (==) does not hold for methods.
>
> Mark
>
> -Original Message-
> From: Mark Rowell [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 10:23
> To: 'OJB Users List'
> Subject: RE: problems with batch-mode=true
>
>
> Hi
>
> Regarding this issue it looks like (at least as far as RC4 is
> concerned) that in the doExecute method of
> PreparedStatementInvocationHandler.java the following line (223) gets
> invoked
>
> ((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
>
> In my case when using batched mode, and JSQLConnect on MSSqlServer I
> get a similar error to Bonnie (java.lang.IllegalArgumentException:
> object is not an instance of declaring class)
>
> The methods returned by _methods.get(i) is
>
> public void
> org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.
> Prepar
> edStatement)
>
> And we are trying to executed it on the statement rather than passing
> the platform instance. I think the problem Is in the if statement in
> that it does an == rather than a .equals() call to determine whether
> we want to call the addBatch method. Now, I do not know whether within
> a single JVM that the following Returns true
>
> Method method1 = obj.getClass().getMethod("methodName", );
> Method method2 = obj.getClass().getMethod("methodName", );
> method1 == method2; // is this gurantee dto be true like it is for
> instances of Class e.g.
>
> Obj.getClass() == Obj.getClass() is guranteed to be true?
>
> Regards,
>
> Mark Rowell
>
>
> -Original Message-
> From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2003 14:02
> To: OJB Users List
> Subject: RE: problems with batch-mode=true
>
>
> Hi,
> Here is the code that I tested. You can
> see that setBatchMode is called before I start
> the tx.
> try
> {
> broker.serviceConnectionManager().setBatchMode(true);
> broker.beginTransaction();
> for (int i = 0; i < 100; i++)
> {
> CustomerInterface customer = new Customer();
> customer.setCustomerNumber("100" + i);
> customer.setFirstName("Big");
> customer.setLastName("Customer");
> customer.setCustomerName("BadCorporation");
> customer.setDeleteTag(Boolean.FALSE);
> broker.store(customer);
> }
> // conMan.executeBatch();
> broker.commitTransaction();
> }
> catch(Exception e)
> {
> e.printStackTrace();
> logger.error(e.getMessage());
> broker.abortTransaction();
> }
> finally
> {
> broker.close();
> }
>
> This chunk of code, exectued with batch-mode="true"
> in repository_database.xml, results in the following
> two exceptions :
> java.lang.IllegalArgumentException: object is not an instance of
declaring
> class
> at java.lang.reflect.Method.invoke(Native Method)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doEx
ecut
> e(Unknown Source)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invo
ke(U
> nknown Source)
> at $Proxy0.doExecute(Unknown Source)
> at
> org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
> Source)
> at
org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
> Source)
> at
>
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unkn
own
> Source)
> at
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
wn
> Source)
> at
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
> nown Source)
> at
>
RE: refresh=true OR refresh=false
Thank you. I supposed, from a performance perspective, if the relationship is ternary, I should have a convenience method that does the setA(A) and A.getBs().add(B) and then I can turn it off to stop the SQL from being executed. Correct? On Thu, 2003-10-23 at 00:32, Charles Anthony wrote: > Hi, > It is indeed to do with caching. > > Let us have a one-to-many relation : A has many Bs. > We modify A (but leave it's related B's alone), and A remains in the cache. > We then create a B, and associate it with A (e.g. b.setA(A) ) - but we > *don't* add it to A's collection of B's. > If we then retrieve A from the Cache as a result of another query. > If refresh = false, then the collection of B's will *not* contain our new B. > If refresh = true, the the collecton will contain the new B - in other words > the collection is refreshed when the object is retrieved from the cache. > > The use of CollectionProxies prevents the actual materialization of all > object in colleciton until needed i.e. the full query is not actually > executed until the contents of the collection is accessed. > > Cheers, > > Charles. > > > -Original Message- > > From: Andy Czerwonka [mailto:[EMAIL PROTECTED] > > Sent: 22 October 2003 23:53 > > To: OJB Users List > > Subject: refresh=true OR refresh=false > > > > > > In looking at the documentation, there isn't really anything > > descriptive > > regarding this attribute on collections/references. I'd like > > to turn it > > off, but I'm afraid. Should I be? Can someone help me > > understand this > > a little better so that I know what's going on? Is this a > > cache thing? > > > > -andy > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > This email and any attachments are strictly confidential and are intended > solely for the addressee. If you are not the intended recipient you must > not disclose, forward, copy or take any action in reliance on this message > or its attachments. If you have received this email in error please notify > the sender as soon as possible and delete it from your computer systems. > Any views or opinions presented are solely those of the author and do not > necessarily reflect those of HPD Software Limited or its affiliates. > > At present the integrity of email across the internet cannot be guaranteed > and messages sent via this medium are potentially at risk. All liability > is excluded to the extent permitted by law for any claims arising as a re- > sult of the use of this medium to transmit information by or to > HPD Software Limited or its affiliates. > > > > - > 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: problems with batch-mode=true
I have the same problem! I thought I was
the only one.
Bonnie MacKellar
-Original Message-
From: Mark Rowell
To: 'OJB Users List'
Sent: 10/23/03 7:59 AM
Subject: RE: problems with batch-mode=true
Armin
No because I am not allowed to use CVS where I work..hence...
Oh well!
Thanks
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 11:37
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi Mark,
did you tried latest version from CVS?
I think your mentioned bug was fixed in
CVS.
See
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/
util
/batch/PreparedStatementInvocationHandler.java
regards,
Armin
Mark Rowell wrote:
> Hi
>
> As a follow on I checked the source for java.lang.reflect.Method and
> it has an implementation Of equals which could possibly indicate tat
> the equality operator (==) does not hold for methods.
>
> Mark
>
> -Original Message-
> From: Mark Rowell [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 10:23
> To: 'OJB Users List'
> Subject: RE: problems with batch-mode=true
>
>
> Hi
>
> Regarding this issue it looks like (at least as far as RC4 is
> concerned) that in the doExecute method of
> PreparedStatementInvocationHandler.java the following line (223) gets
> invoked
>
> ((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
>
> In my case when using batched mode, and JSQLConnect on MSSqlServer I
> get a similar error to Bonnie (java.lang.IllegalArgumentException:
> object is not an instance of declaring class)
>
> The methods returned by _methods.get(i) is
>
> public void
> org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.
> Prepar
> edStatement)
>
> And we are trying to executed it on the statement rather than passing
> the platform instance. I think the problem Is in the if statement in
> that it does an == rather than a .equals() call to determine whether
> we want to call the addBatch method. Now, I do not know whether within
> a single JVM that the following Returns true
>
> Method method1 = obj.getClass().getMethod("methodName", );
> Method method2 = obj.getClass().getMethod("methodName", );
> method1 == method2; // is this gurantee dto be true like it is for
> instances of Class e.g.
>
> Obj.getClass() == Obj.getClass() is guranteed to be true?
>
> Regards,
>
> Mark Rowell
>
>
> -Original Message-
> From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2003 14:02
> To: OJB Users List
> Subject: RE: problems with batch-mode=true
>
>
> Hi,
> Here is the code that I tested. You can
> see that setBatchMode is called before I start
> the tx.
> try
> {
> broker.serviceConnectionManager().setBatchMode(true);
> broker.beginTransaction();
> for (int i = 0; i < 100; i++)
> {
> CustomerInterface customer = new Customer();
> customer.setCustomerNumber("100" + i);
> customer.setFirstName("Big");
> customer.setLastName("Customer");
> customer.setCustomerName("BadCorporation");
> customer.setDeleteTag(Boolean.FALSE);
> broker.store(customer);
> }
> // conMan.executeBatch();
> broker.commitTransaction();
> }
> catch(Exception e)
> {
> e.printStackTrace();
> logger.error(e.getMessage());
> broker.abortTransaction();
> }
> finally
> {
> broker.close();
> }
>
> This chunk of code, exectued with batch-mode="true"
> in repository_database.xml, results in the following
> two exceptions :
> java.lang.IllegalArgumentException: object is not an instance of
declaring
> class
> at java.lang.reflect.Method.invoke(Native Method)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doEx
ecut
> e(Unknown Source)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invo
ke(U
> nknown Source)
> at $Proxy0.doExecute(Unknown Source)
> at
> org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
> Source)
> at
org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
> Source)
> at
>
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unkn
own
> Source)
> at
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
wn
> Source)
> at
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
> nown Source)
> at
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
> nown Source)
> at
>
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMi
grat
> ion.java:69)
> 3425 ERROR [main] dbmigrationutils
RE: problems with batch-mode=true
Armin
No because I am not allowed to use CVS where I work..hence...
Oh well!
Thanks
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 11:37
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi Mark,
did you tried latest version from CVS?
I think your mentioned bug was fixed in
CVS.
See
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/util
/batch/PreparedStatementInvocationHandler.java
regards,
Armin
Mark Rowell wrote:
> Hi
>
> As a follow on I checked the source for java.lang.reflect.Method and
> it has an implementation Of equals which could possibly indicate tat
> the equality operator (==) does not hold for methods.
>
> Mark
>
> -Original Message-
> From: Mark Rowell [mailto:[EMAIL PROTECTED]
> Sent: 23 October 2003 10:23
> To: 'OJB Users List'
> Subject: RE: problems with batch-mode=true
>
>
> Hi
>
> Regarding this issue it looks like (at least as far as RC4 is
> concerned) that in the doExecute method of
> PreparedStatementInvocationHandler.java the following line (223) gets
> invoked
>
> ((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
>
> In my case when using batched mode, and JSQLConnect on MSSqlServer I
> get a similar error to Bonnie (java.lang.IllegalArgumentException:
> object is not an instance of declaring class)
>
> The methods returned by _methods.get(i) is
>
> public void
> org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.
> Prepar
> edStatement)
>
> And we are trying to executed it on the statement rather than passing
> the platform instance. I think the problem Is in the if statement in
> that it does an == rather than a .equals() call to determine whether
> we want to call the addBatch method. Now, I do not know whether within
> a single JVM that the following Returns true
>
> Method method1 = obj.getClass().getMethod("methodName", );
> Method method2 = obj.getClass().getMethod("methodName", );
> method1 == method2; // is this gurantee dto be true like it is for
> instances of Class e.g.
>
> Obj.getClass() == Obj.getClass() is guranteed to be true?
>
> Regards,
>
> Mark Rowell
>
>
> -Original Message-
> From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
> Sent: 22 October 2003 14:02
> To: OJB Users List
> Subject: RE: problems with batch-mode=true
>
>
> Hi,
> Here is the code that I tested. You can
> see that setBatchMode is called before I start
> the tx.
> try
> {
> broker.serviceConnectionManager().setBatchMode(true);
> broker.beginTransaction();
> for (int i = 0; i < 100; i++)
> {
> CustomerInterface customer = new Customer();
> customer.setCustomerNumber("100" + i);
> customer.setFirstName("Big");
> customer.setLastName("Customer");
> customer.setCustomerName("BadCorporation");
> customer.setDeleteTag(Boolean.FALSE);
> broker.store(customer);
> }
> // conMan.executeBatch();
> broker.commitTransaction();
> }
> catch(Exception e)
> {
> e.printStackTrace();
> logger.error(e.getMessage());
> broker.abortTransaction();
> }
> finally
> {
> broker.close();
> }
>
> This chunk of code, exectued with batch-mode="true"
> in repository_database.xml, results in the following
> two exceptions :
> java.lang.IllegalArgumentException: object is not an instance of declaring
> class
> at java.lang.reflect.Method.invoke(Native Method)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
> e(Unknown Source)
> at
>
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
> nknown Source)
> at $Proxy0.doExecute(Unknown Source)
> at
> org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
> Source)
> at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
> Source)
> at
>
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
> Source)
> at
> org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
> Source)
> at
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
> nown Source)
> at
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
> nown Source)
> at
>
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
> ion.java:69)
> 3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
> instance of declaring class
> 3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
> [EMAIL PROTECTED]
> org.apache.ojb.broker.TransactionNotInProgressExceptio
Re: problems with batch-mode=true
Hi Mark,
did you tried latest version from CVS?
I think your mentioned bug was fixed in
CVS.
See
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/util/batch/PreparedStatementInvocationHandler.java
regards,
Armin
Mark Rowell wrote:
Hi
As a follow on I checked the source for java.lang.reflect.Method and it has
an implementation
Of equals which could possibly indicate tat the equality operator (==) does
not hold for methods.
Mark
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:23
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method of PreparedStatementInvocationHandler.java the
following line (223) gets invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to Bonnie (java.lang.IllegalArgumentException: object is not
an instance of declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem Is in the if statement in that it
does an == rather than a .equals() call to determine whether we want to call
the addBatch method. Now, I do not know whether within a single JVM that the
following Returns true
Method method1 = obj.getClass().getMethod("methodName", ); Method
method2 = obj.getClass().getMethod("methodName", ); method1 ==
method2; // is this gurantee dto be true like it is for instances of Class
e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the call
RE: problems with batch-mode=true
Hi,
Yes, I had tracked it down to this code segment yesterday, but
wasn't sure how to proceed.
thanks,
Bonnie MacKellar
-Original Message-
From: Mark Rowell
To: 'OJB Users List'
Sent: 10/23/03 5:23 AM
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method
of PreparedStatementInvocationHandler.java the following line (223) gets
invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get
a
similar error to
Bonnie (java.lang.IllegalArgumentException: object is not an instance of
declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Pr
epar
edStatement)
And we are trying to executed it on the statement rather than passing
the
platform instance. I think the problem
Is in the if statement in that it does an == rather than a .equals()
call to
determine whether we
want to call the addBatch method. Now, I do not know whether within a
single
JVM that the following
Returns true
Method method1 = obj.getClass().getMethod("methodName", );
Method method2 = obj.getClass().getMethod("methodName", );
method1 == method2; // is this gurantee dto be true like it is for
instances
of Class e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of
declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doEx
ecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invo
ke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unkn
own
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
wn
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMi
grat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException:
ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknow
n
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(
Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(
Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMi
grat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the
call to
abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode="false".
And, if I call executeBatch, I don't get the second exception (the one
about
not being in
a transaction), although I still get the first transaction.
I am including my repository_database.xml as an attachment. I
RE: problems with batch-mode=true
Hi
Sorry for the flurry of emails but changing == to .equals in the doExecute
method of
PreparedStatementInvocationHandler fixes this problem.
Change line 214 in RC4 from
if ( ((Method)_methods.get(i)) ==
ADD_BATCH )
{
/**
* we invoke on the platform
and pass the stmt as an arg.
*/
((Method)
_methods.get(i)).invoke(m_platform, new Object[] {stmt});
}
else
{
((Method)
_methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
}
if ( ADD_BATCH.equals(
_methods.get(i)) )
{
/**
* we invoke on the platform
and pass the stmt as an arg.
*/
((Method)
_methods.get(i)).invoke(m_platform, new Object[] {stmt});
}
else
{
((Method)
_methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
}
BTW the cast in the equality is unecessary.
Regards
Mark Rowell
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:27
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
As a follow on I checked the source for java.lang.reflect.Method and it has
an implementation Of equals which could possibly indicate tat the equality
operator (==) does not hold for methods.
Mark
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:23
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method of PreparedStatementInvocationHandler.java the
following line (223) gets invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to Bonnie (java.lang.IllegalArgumentException: object is not
an instance of declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem Is in the if statement in that it
does an == rather than a .equals() call to determine whether we want to call
the addBatch method. Now, I do not know whether within a single JVM that the
following Returns true
Method method1 = obj.getClass().getMethod("methodName", ); Method
method2 = obj.getClass().getMethod("methodName", ); method1 ==
method2; // is this gurantee dto be true like it is for instances of Class
e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocation
RE: problems with batch-mode=true
Hi
As a follow on I checked the source for java.lang.reflect.Method and it has
an implementation
Of equals which could possibly indicate tat the equality operator (==) does
not hold for methods.
Mark
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:23
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method of PreparedStatementInvocationHandler.java the
following line (223) gets invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to Bonnie (java.lang.IllegalArgumentException: object is not
an instance of declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem Is in the if statement in that it
does an == rather than a .equals() call to determine whether we want to call
the addBatch method. Now, I do not know whether within a single JVM that the
following Returns true
Method method1 = obj.getClass().getMethod("methodName", ); Method
method2 = obj.getClass().getMethod("methodName", ); method1 ==
method2; // is this gurantee dto be true like it is for instances of Class
e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the call to
abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode="false".
And, if I call executeBatch, I don't get the second exception (the one about
not being in
a transaction), althoug
RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method
of PreparedStatementInvocationHandler.java the following line (223) gets
invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get a
similar error to
Bonnie (java.lang.IllegalArgumentException: object is not an instance of
declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Prepar
edStatement)
And we are trying to executed it on the statement rather than passing the
platform instance. I think the problem
Is in the if statement in that it does an == rather than a .equals() call to
determine whether we
want to call the addBatch method. Now, I do not know whether within a single
JVM that the following
Returns true
Method method1 = obj.getClass().getMethod("methodName", );
Method method2 = obj.getClass().getMethod("methodName", );
method1 == method2; // is this gurantee dto be true like it is for instances
of Class e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i < 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber("100" + i);
customer.setFirstName("Big");
customer.setLastName("Customer");
customer.setCustomerName("BadCorporation");
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode="true"
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:75)
Exception in thread "main"
It looks like the persistence broker is being closed down before the call to
abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode="false".
And, if I call executeBatch, I don't get the second exception (the one about
not being in
a transaction), although I still get the first transaction.
I am including my repository_database.xml as an attachment. It is always
possible that
I am doing something terribly wrong there. The relevant jcd-alias is
"ActiveBillStandalone"
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
> -Original Message-
> From: Armin Waib
Rollback with Inheritance mapping...
I'm having some trouble using the PersistenceBroker to perform rollback on an object
mapped with a simple inheritance hierarchy.
Here's how my classes are configured:
public class TNObject
{
private Integer id;
private String comment;
// (setters and getters)
}
public class TNHost extends TNObject
{
private Integer type;
private String name;
// (setters and getters)
}
If I insert record by the store() method (a TNHost object) and it's failed because
internal database integrity was not respected (field 'type' was NULL for example), I
have a record in the TNObject table even if I abort the transaction...
This is my code:
PersistenceBroker _broker = PersistenceBrokerFactory.defaultPersistenceBroker();
try
{
_broker.beginTransaction();
_broker.store(myHost);
_broker.commitTransaction();
}
catch (PersistenceBrokerException pbe) {
_broker.abortTransaction();
System.out.println(pbe.getMessage());
pbe.printStackTrace();
}
So, what's wrong
Thanks for your help.
Thomas
AW: AW: Character set mismatch error in Oracle
Hello Patrick,
ok, here's my suspicion:
The problem is caused by the field CONTENT NVARCHAR2(1).
You declared it as a unicode field in the database. I think if you used VARCHAR2(1),
it would work (but you propably had a good reason for chosing NCHAR).
Well, i have no experience with NCHAR and JDBC with OJB (maybe someone else can give a
more qualified answer).
Here's a testcase that shows the problem from a SQL point of view:
case1
=
create table test1 (a char(10));
insert into table test1 values('abc'); -> works
insert into table test1 values(N'abc'); -> doesn't work
(the N'..' tells the server that the string
is in unicaode)
case2
=
create table test2 (a nchar(10));
insert into table test1 values('abc'); -> doesn't work (i think this is your problem)
insert into table test1 values(N'abc'); -> works (this is what you would like to have)
As far as i understand it:
In java you work with unicode charset, the driver tries to transform this unicode
values to the charset your database works with (for CHAR fields).In your case this
transformation takes place, but the the value should be stored in a NCHAR field (where
no transformation should have happend )
And now:
- i don't know if there is a way to tell ojb to generate the N'...' notation
- there are NLS conversions that the jdbc driver performs automatically,
do you have the file nls_charset12.zip in your classpath
- if you dont actuelly need the unicode field, change your database to CHAR fields
- maybe you can create your database not with WE8ISO8859P1 or something like that, but
with
UNICODE as default characterset for CHAR fields
Sorry, that i don't have the ultimate solution for you, but maybe i helped to fine a
viable solution.
Regards
Max
> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 23. Oktober 2003 07:57
> An: OJB Users List
> Cc: OJB Users List
> Betreff: Re: AW: Character set mismatch error in Oracle
>
>
>
>
>
>
>
> Yep, sorry I forgot to include this information here it is:
>
> isolation-level="read-uncommitted">
>jcd-alias=""
> default-connection="true"
> platform="Oracle"
> jdbc-level="2.0"
> driver="oracle.jdbc.driver.OracleDriver"
> protocol="jdbc"
> subprotocol="oracle:thin"
> dbalias="@gvo2appd12:1521:EFAX817"
> username="***"
> password="***"
> batch-mode="false"
> >
>
>className="org.apache.ojb.broker.util.sequence.SequenceManager
> HighLowImpl">
>
>
>
>
> - with which character set did you create your database
>
> The database was created by our DBA, but he is out for the
> week :-( How do
> I check this ?
>
> - how does the CREATE TABLE statement look like (esp. the
> datatype in the
> database)
>
> CREATE TABLE EFAX.MESSAGE
> (ID INTEGER NOT NULL,
>CONTENT NVARCHAR2(1) NOT NULL,
>STATUS INTEGER NOT NULL,
>CREATION_DATE DATE NOT NULL,
>MODIFICATION_DATE DATE NOT NULL);
>
> - (well, and maybe the p6spy output of the actual statement
> sent to the
> database=
>
> If only I knew how to use p6spy I would ? Where can I find
> doc on this tool
> ?
>
> Thanks and regards,
>
> Patrick Reyes
>
>
>
>
>
> "Geigl
>
>
> Maximilian, R235"To: "OJB
> Users List" <[EMAIL PROTECTED]>
>
>(bcc: Patrick Reyes/CDS/CG/CAPITAL)
>
> @akdb.de>Subject: AW:
> Character set mismatch error in Oracle
>
>
>
>
> 10/22/2003 05:53
>
>
> PM
>
>
> Please respond to
>
>
> "OJB Users List"
>
>
>
>
>
>
>
>
Inheritance & delete
Hello, I still have some problems deleting record of inherited tables/classes. I've - class A extending B like those in "mapping inheritance hierarchies" tutorial - table A and B like those in "mapping classes on multiple joined tables" docs. When I store a record in table B, is also stored a record in table A with the same primary key. When I delete a record from table B, OJB doesn't deleted the record in table A with the same key. I don't understand this asymmetric behaviour. Probably there is something wrong in my code. Thank you - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mapping
Hi, Problem is that an class name attribute is empty. It seems that your first extent-class has an incorrectly spelled class-ref attribute (you have calls-ref). Cheers, Charles. > -Original Message- > From: Reitsam Andreas [mailto:[EMAIL PROTECTED] > Sent: 23 October 2003 08:18 > To: Ojb-User (E-Mail) > Subject: mapping > > > Hello. > > I tried to map multiple inteface inheritance like this: > > >class="de.sigel.business.mvgl.bo.Preis"> >calss-ref="de.sigel.business.mvgl.bo.MitbewerbervergleichPreis"/> >class-ref="de.sigel.business.mvgl.bo.KundenListPreisImpl" /> > > > >class="de.sigel.business.mvgl.bo.MitbewerbervergleichPreis"> >class-ref="de.sigel.business.mvgl.bo.KonkurrenzKundenPreisImpl" /> >class-ref="de.sigel.business.mvgl.bo.KonkurrenzHaendlerPreisImpl" /> >class-ref="de.sigel.business.mvgl.bo.SigelHaendlerPreisImpl" /> >class-ref="de.sigel.business.mvgl.bo.SigelKundenPreisImpl" /> > > > >class="de.sigel.business.mvgl.bo.KonkurrenzKundenPreisImpl" > table="TEST_PREISE"> > > name="ojbConcreteClass" > column="CLASS_NAME" > jdbc-type="VARCHAR"/> > > > > What's wrong with this, because a NullPointerException is thrown. > > java.lang.NullPointerException > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:219) > at > org.apache.ojb.broker.util.ClassHelper.getClass(Unknown Source) > at > org.apache.ojb.broker.util.ClassHelper.getClass(Unknown Source) > at > org.apache.ojb.broker.metadata.ClassDescriptor.getExtentClasse > s(Unknown > Source) > at > org.apache.ojb.broker.query.QueryFactory.getExtentClasses(Unknown > Source) > at > org.apache.ojb.broker.query.QueryFactory.addCriteriaForOjbConc > reteClasses(Un > known Source) > at > org.apache.ojb.broker.query.QueryFactory.newQuery(Unknown Source) > at > org.apache.ojb.broker.query.QueryFactory.newQuery(Unknown Source) > > > > thx, > andreas > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > This email and any attachments are strictly confidential and are intended solely for the addressee. If you are not the intended recipient you must not disclose, forward, copy or take any action in reliance on this message or its attachments. If you have received this email in error please notify the sender as soon as possible and delete it from your computer systems. Any views or opinions presented are solely those of the author and do not necessarily reflect those of HPD Software Limited or its affiliates. At present the integrity of email across the internet cannot be guaranteed and messages sent via this medium are potentially at risk. All liability is excluded to the extent permitted by law for any claims arising as a re- sult of the use of this medium to transmit information by or to HPD Software Limited or its affiliates. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: check Batchmode problem with DB2 on z/OS with ojb 1.0.rc4
Hi Gerhard
yes I saw it also the error is ignored.
thanks
Matthias
-Original Message-
From: Gerhard Grosse [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 22. Oktober 2003 09:29
To: [EMAIL PROTECTED]
Subject: Re: check Batchmode problem with DB2 on z/OS with ojb 1.0.rc4
Hi Matthias,
I am seeing an AbstractMethodError (partial stack trace below) in my
logs whenever OJB first initializes a JDBC connection from the DB2
JDBC driver. Obviously OJB is checking for batch support even if
batch-mode=false is set in repository.xml. However, in my case the
error is silently ignored and does not cause any further problems.
I'm using CVS HEAD (almost), Windows XP, Websphere, DB2 and IBM's
category 2 JDBC driver.
Gerhard
ERROR ojb.broker.platforms.PlatformDefaultImpl - batch support check
failed
java.lang.AbstractMethodError:
COM/ibm/db2/jdbc/app/DB2DatabaseMetaData.supportsBatchUpdates
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.checkForBatchSupport(Pla
tformDefaultImpl.java:106)
at
org.apache.ojb.broker.platforms.PlatformDefaultImpl.initializeJdbcConnection
(PlatformDefaultImpl.java:180)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.initializeJd
bcConnection(ConnectionFactoryAbstractImpl.java:138)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectio
nFromDataSource(ConnectionFactoryAbstractImpl.java:210)
at
org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnec
tion(ConnectionFactoryAbstractImpl.java:97)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Connec
tionManagerImpl.java:135)
at
org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(Stat
ementManager.java:710)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(JdbcAccessImpl
.java:327)
...
On Tue, 21 Oct 2003 23:33:03 +0200, "Matthias Roth"
<[EMAIL PROTECTED]> wrote:
>Hi
>
>does the SequenceManagerHighLowImpl check for batchmode by creating
>a new broker instance in getSequence(...){
>...
>PersistenceBrokerFactory.createPersistenceBroker(brokerForSequence.getPBKey
(
>))
>...
>}
>
>I get an db2 jdbc error (ONLY jdbc driver on z/OS) if the first getSequence
>is called. The error
>tells that batch mode is not suported. But in the repository.xml file I set
>batch-mode="false".
>
>Have had some body also this problem?
>
>
>
>regards
>Matthias Roth
>Dipl. Ing. HTL
>in Wirtschaftsinformatik
>
>impart Software Engineering GmbH
>Chasseralstrasse 13
>Postfach
>CH-3063 Ittigen
>
>Phone +41 (0)31 922 39 25
>Fax +41 (0)31 922 39 18
>EMail mailto:[EMAIL PROTECTED]
>Homepagehttp://www.impart.ch
-
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]
mapping
Hello. I tried to map multiple inteface inheritance like this: What's wrong with this, because a NullPointerException is thrown. java.lang.NullPointerException at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:219) at org.apache.ojb.broker.util.ClassHelper.getClass(Unknown Source) at org.apache.ojb.broker.util.ClassHelper.getClass(Unknown Source) at org.apache.ojb.broker.metadata.ClassDescriptor.getExtentClasses(Unknown Source) at org.apache.ojb.broker.query.QueryFactory.getExtentClasses(Unknown Source) at org.apache.ojb.broker.query.QueryFactory.addCriteriaForOjbConcreteClasses(Un known Source) at org.apache.ojb.broker.query.QueryFactory.newQuery(Unknown Source) at org.apache.ojb.broker.query.QueryFactory.newQuery(Unknown Source) thx, andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: check Batchmode problem with DB2 on z/OS with ojb 1.0.rc4
Hi Armin
I use ojb 1.0.rc4 (not the newest cvs version)
regards
Matthias
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 21. Oktober 2003 23:43
To: OJB Users List
Subject: Re: check Batchmode problem with DB2 on z/OS with ojb 1.0.rc4
Hi Matthias,
On Tue, 21 Oct 2003 23:33:03 +0200, Matthias Roth
<[EMAIL PROTECTED]> wrote:
> Hi
>
> does the SequenceManagerHighLowImpl check for batchmode by creating
> a new broker instance in getSequence(...){
> ...
>
PersistenceBrokerFactory.createPersistenceBroker(brokerForSequence.getPBKey(
> ))
> ...
> }
>
> I get an db2 jdbc error (ONLY jdbc driver on z/OS) if the first
> getSequence
> is called. The error
> tells that batch mode is not suported. But in the repository.xml file I
> set
> batch-mode="false".
>
> Have had some body also this problem?
>
Which version do you use?
regards,
Armin
>
>
> regards
> Matthias Roth
> Dipl. Ing. HTL
> in Wirtschaftsinformatik
>
> impart Software Engineering GmbH
> Chasseralstrasse 13
> Postfach
> CH-3063 Ittigen
>
> Phone +41 (0)31 922 39 25
> Fax +41 (0)31 922 39 18
> EMail mailto:[EMAIL PROTECTED]
> Homepagehttp://www.impart.ch
>
-
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]
