Re: [eclipselink-users] Virtual Metlhods | questions

[gaurav malhotra <gaurav.malhotra@xxxxxxxxxx>]

I understand the problem, but I don't know how to fix it.
1) I am recording all the changes (we store them in the database)
2) I don't know how to signal that session needs to pick them using 
refreshMetadata.  Does this mean using SessionEventAdapter?? If yes then 
which method(s) should I use. As per my understanding refreshMetadata 
should be only called once if there are recorded changes. When recorded 
changes has been pushed to session, then there is no need to 
refreshMetadata. It will be great if you point me some code snippets.

Also, my product, is a claim processing system (with millions of 
transactions handled in a day). What is the impact of refreshMetadata on 
the running transactions?? We dont expect setup for the dynamic fields 
change every another minute or a day??

On 25-07-2012 12:04 AM, Christopher Delahunt wrote:
> Through a metadata source repository, or the customizer approach.  Your app must record the changes that are needed somehow and then signal that the session needs to pick them up using refreshMetadata.  The app should not directly change the running session.
>
> On 2012-07-24, at 5:47 PM, gaurav malhotra <gaurav.malhotra@xxxxxxxxxx> wrote:
>
> > Hi Chris,
> >   It's the requirement of my product - Dynamic Fields can be configured at the runtime and should be picked up in live application with zero down time. Its for the dynamic fields I am creating the mappings.
> >   How to accomplish above reqirement?
> >
> > ~Gaurav
> > On 24-07-2012 11:29 PM, Christopher Delahunt wrote:
> > > This would occur if the mapping has not been initialized; initialization occurs during session login.  Earlier posts showed mappings being added through a session customizer which get called prior to login.  How and when is this mapping added?
> > >
> > > Calling refreshMetadata as Tom mentions creates a new session from the metadata, and would call customizers on it before logging in. If your customizer picks up the new mapping changes, then that might explain why it works for you, since they get initialized with the new session login.
> > >
> > > It is not a good idea to make mapping/descriptor changes to active sessions after login has occurred.
> > >
> > > On 24/07/2012 5:05 PM, gaurav malhotra wrote:
> > > > ava.lang.NullPointerException
> > > >      at
> > > > org.eclipse.persistence.mappings.ForeignReferenceMapping.valueFromRowInternal(ForeignReferenceMapping.java:2019)
> > > >
> > > >      at
> > > > org.eclipse.persistence.mappings.ForeignReferenceMapping.valueFromRow(ForeignReferenceMapping.java:1987)
> > > >
> > > >      at
> > > > org.eclipse.persistence.mappings.ForeignReferenceMapping.buildCloneFromRow(ForeignReferenceMapping.java:276)
> > > >
> > > >      at
> > > > org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildAttributesIntoWorkingCopyClone(ObjectBuilder.java:1548)
> > > >
> > > >      at
> > > > org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildWorkingCopyCloneFromRow(ObjectBuilder.java:1694)
> > > >
> > > >      at
> > > > org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObjectInUnitOfWork(ObjectBuilder.java:664)
> > > >
> > > >      at
> > > > org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:601)
> > > >
> > > >      at
> > > > org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildObject(ObjectBuilder.java:560)
> > > >
> > > >      at
> > > > org.eclipse.persistence.queries.ObjectLevelReadQuery.buildObject(ObjectLevelReadQuery.java:717)
> > > >
> > > >      at
> > > > org.eclipse.persistence.queries.ReadAllQuery.registerResultInUnitOfWork(ReadAllQuery.java:769)
> > > _______________________________________________
> > > eclipselink-users mailing list
> > > eclipselink-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/eclipselink-users