Eager Fetch Mode limit clarification

Hi,
I would like clarification of the following from the 3.3.4 docs
(kodo-jdo-3.3.4/docs/ref_guide_perfpack_eager.html):
"Once Kodo eager-joins into a class, it cannot issue any further eager
to-many joins or parallel selects from that class in the same query.
To-one joins, however, can recurse to any level."
Given the following class/table relationships:
X --> Y -->> Z
(where --> is one-to-one and -->> is one-to-many)
Does this mean that if I query X, Y can be eagerly fetched, but not Z?
This is certainly what we see - a join to fetch X and Y in one select
statement and then many one-off selects from Z for each Y.
Is there any way to load Z more efficiently? It would seem that once
Kodo has loaded the Y's that it knows all it needs to load the Z's with
one SQL select - Z would have a FK to Y, so "select ... from z where
y_id in (<kodo puts the loaded y ids here>)" would seem feasible,
especially given Kodo does this in other places.
Thanks,
Richard

Thanks Abe.
Abe White wrote:
X --> Y -->> Z
(where --> is one-to-one and -->> is one-to-many)
Does this mean that if I query X, Y can be eagerly fetched, but not Z?Yes, unfortunately.Our actual case also includes the following relationships: X -->> W -->>
V and strangely, they do seem to be be eagerly loaded when we query for
X. i.e. one query to load all Vs. How does this work given the above?
Is there any way to load Z more efficiently?Typical workarounds include querying for Y's instead of X's and using
the inverse relation from Y to X, or if there is no such relation,
performing 2 queries: one for Y's and one for X's.Are there any plans to support greater depth eager loadings in any
upcoming Kodo version?
Thanks again for your help,
Richard

Similar Messages

  • SQL Batch doesn't seem to work; How to eager-fetch related objects?

    Hi,
    I have two technical questions with Kodo.
    1. SQL Batch doesn't seem to work. I have tried batch size of -1, 0, 1, 25.
    But the performance from batch creating objects is not affected by batch
    size.
    kodo.jdbc.DBDictionary: BatchLimit=25
    2. How to use custom fetch groups to eagerly fetch related persistable
    objects? Example only showed attributes, not relationships.
    Enviroment:
    * Kodo 3.1.0 RC1
    * Oracle 9i release 1.
    Qingshan Luo
    Senior Software Engineer
    Open Harbor
    1123 Industrial Road
    San Carlos, CA 94070
    Phone: 650-413-4251
    Fax: 650-413-4298

    try poracle 10g driver. At least they fixed terrible CLOB bug may be batch
    to. BTW 9.2.x has problem with batching with deferred constraints so be
    careful
    "Greg Campbell" <[email protected]> wrote in message
    news:c3dmnu$rmj$[email protected]..
    >
    "Qingshan Luo" <[email protected]> wrote in message
    news:c3dg7q$mdl$[email protected]..
    Hi,
    I have two technical questions with Kodo.
    1. SQL Batch doesn't seem to work. I have tried batch size of -1, 0, 1,25.
    But the performance from batch creating objects is not affected by batch
    size.
    kodo.jdbc.DBDictionary: BatchLimit=25You may be running into a bug in the Oracle 9.2 driver. That driverdoesn't
    reliably give update counts when using batching and prepared statement
    caching. By default, Kodo will turn off batching. You can manuallyenable
    batching by setting the BatchLimit on your DBDictionary, as you've done.If
    you do this, though, you may want to turn off prepared statement cachingby
    setting MaxCachedStatements to 0 (see
    http://www.solarmetric.com/Software/Documentation/3.1.0RC1/docs/ref_guide_dbsetup.html#ref_guide_dbsetup_builtin).
    >
    2. How to use custom fetch groups to eagerly fetch related persistable
    objects? Example only showed attributes, not relationships.You can find information on setting up eager fetching of relations at
    http://www.solarmetric.com/Software/Documentation/3.0.3/docs/ref_guide_
    perfpack_eager.html
    Basically, you'll need to add the relations to your fetch group, and
    set the eager fetching mode.
    Enviroment:
    * Kodo 3.1.0 RC1
    * Oracle 9i release 1.
    Qingshan Luo
    Senior Software Engineer
    Open Harbor
    1123 Industrial Road
    San Carlos, CA 94070
    Phone: 650-413-4251
    Fax: 650-413-4298

  • Eager fetching in multiple mode

    Hi,
    I have the following questions about eager fetching in multiple mode :
    - for a to-many relation or collection field, what kind of join is used
    for the separate select statement ?
    - in my understanding, the gain in performance is due to the use of
    batched select statements : is it correct or did I miss something here ?
    Thanks in advance.
    Regards.

    - for a to-many relation or collection field, what kind of join is used
    for the separate select statement ?Inner. For a 2-many, there is no need for an outer join.
    - in my understanding, the gain in performance is due to the use of
    batched select statements : is it correct or did I miss something here ?The performance gain results from using a single SELECT per to-many
    relation, rather than a SELECT per to-many relation, per object. For
    example, let's say my Query matches 10 Project objects, and each Project
    has 10 SubProjects, and each SubProject has some Workers. If I wanted
    to retrieve all that data lazily, I would end up with 111 SELECTs:
    1 SELECT for Projects matching the query
    + 10 SELECTs as I retrieve the SubProject relation from each of the 10
    Project
    + 100 SELECTs as I retrieve the Workers relation from each of the 100
    SubProjects (10 Projects with 10 SubProjects each).
    With eager fetching, all the data is retrieved in 3 SELECTs instead:
    1 SELECT for Projects matching the query
    1 SELECT for SubProjects of the Projects matching the query
    1 SELECT for Workers of the SubProjects of the Projects matching the query

  • Problem with URL iView regarding fetch mode and SSO to non-sap webapps

    Hi,
    I have created an URL iView which opens an internal webapp. When the fetch mode is set to client-side the page is displayed for the user. But when I set the fetch mode to server-side, the page cannot be displayed by the user.
    No proxy is needed. I tried to open the wepapp direcly on the portal server without any problem. Are there any additional points to be considered?
    On the other hand I want to realize SSO to this webapp (form based authentication) with user mapping. Is it correct, that I have to user server-side fetch mode, when I want to use the POST request method?
    Thanks ahead,
    Bernd

    >
    Bernd Speckmann wrote:
    > On the other hand I want to realize SSO to this webapp (form based authentication) with user mapping. Is it correct, that I have to user server-side fetch mode, when I want to use the POST request method?
    Yes.
    >Are there any additional points to be considered?
    Have a look at System Administration - System Configuration - Service Configuration - Applications - com.sap.portal.ivs.httpservice
    This is used to do the Server side fetch.
    Have fun
    Johannes

  • Fetch Mode for association RowIterators

    Hello all,
    In Jdev 3.2, I saw that a new "tuning" tab appeared in the view object wizard.
    In the corresponding help pages we can read the following "If As needed is specified and too many row sets are open (and left open because they are not navigated to the end), the user may run out of result sets and get a DMLException exception (You can set the jbo.max.cursors runtime parameter to a higher number, if needed.)"
    If I'm not mistaken, when 2 entities (e.g. dept, emp) are linked by a 1:n association, the entity on the 1 side of the 1:n association gets an accessor which returns a RowIterator.
    for instance, in DeptImpl, I'll have a getEmp() accessor which returns a RowIterator containing EmpImpl entities, right?
    So I'm just wondering what will be the fetch mode for this iterator.
    The part about "...left open because they are not navigated to the end..." worries me a bit.
    If these RowIterators use the "as needed mode",
    how can I be sure that they are properly closed when I'm finished using them?
    is there a RowIterator.close() method? (I haven't seen one)
    Should I just navigate till the end of the RowSet?
    I'm having quite a lot of Maximum open cursors exceeded exceptions on one of my programs, which makes extensive use of associations RowIterators, so I'm wondering if this could be the cause...
    Thanks in advance for any help.
    Remi

    Ravi,
    Great question. The iterators returned from association accessors use "Fetch as Needed" mode. So, if you are not exhausting the rows from an iterator (i.e. fetching all the rows) then the cursor will stay open.
    In the 3.2.3 maintenance release, there is a new close() method on oracle.jbo.RowIterator so that you can prematurely close the cursor if you want.
    In 3.2.2, unfortunately the only way to make sure the cursor gets closed is to fetch all the rows from the iterator.

  • Eager fetching

    I believe eager fetching can greatly benefit from more dynamic method then
    predefined fetch groups.
    Different queries pull different parts of object graph and only client using
    object model knows what's needed for a particular query. Trying to fit
    conflicting data needs into one set of fetch group is a challenge. While I
    would retain this feature I would like to propose field based eager fetching
    control. Which can also be used for Detached objects
    Lets say we have PO with POLine collection and each POLine references
    Product. If we want to eager fetch POs along with their lines and products
    we could say something like
    pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class, "lines");
    pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class,
    "lines/product");
    or
    pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class, pathList);
    of course we would need
    pm.getFetchConfiguration().removePath(com.peacetech.sales.PO.class,
    "lines/product");
    pm.getFetchConfiguration().addPath(com.peacetech.sales.PO.class); //remove
    all for given class
    This is just a crude example. In real life we should have few classes to
    support the idea and main class GraphConfig or something so users can
    configure, build and reuse those GraphConfig instances and use them for
    various purposes like eager fetching and detaching without conflicts
    I think it would be enormous help to uncouple so many conflicting issues
    (fetch optimizations, optimistic locking field groups, detached graphs etc)
    from one very limited concept of predefined fetch groups

    Mark,
    I mentioned this possibility in on of my prior posts. It is not exactly what
    I want (since it lack interclass relations which let you express hints for
    deep graph rather than for a class and its fields) but close.
    If you maintain your metadata files by hand it is too much effort but since
    almost all my models and metadata are generated I can easily do (and undo)
    it for each and every class/field and I will give it a try :-)
    Alex
    "Marc Prud'hommeaux" <[email protected]> wrote in message
    news:[email protected]...
    Alex-
    Well, you could always simulate dynamic fetch groups by defining a
    different custom fetch group for each field (provided your license has
    the capability to use custom fetch groups). For simplicity, you could
    name each fetch group to be "ClassName.fieldName".
    That way, you could do something like this:
    KodoQuery kq = (KodoQuery) pm.newQuery (MyClass.class, "someQuery");
    kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldA");
    kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldB");
    kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldC");
    kq.getFetchConfiguration ().addFetchGroup ("MyClass.fieldD");
    Collection results = (Collection) kq.execute ();
    It would them be pretty simple to make a static helper method that will
    do thing like includeAllFieldsInFatchGroup() or
    includeNoFieldsInFetchGroup().
    In article <[email protected]>, Alex Roytman wrote:
    David Tinker says multiple fetch group is the solution:
    Hi Alex
    You can create as many fetch groups as you like in the meta data (with
    JDO
    Genie anyway). I think it is much better to get tuning information likethis
    out of the code. It should be added externally much like you add indexesto
    database tables in response to query search requirements. I understandthat
    sometimes you will need programatic control but mostly it is better notto
    pollute the code.
    JDO 2.0 is going to standardize the concept of a use-case. This willdelimit
    business operations to the JDO implementation so it can applyappropriate
    meta-data defined fetch groups or locking strategies. You will be ableto
    use a vendor supplied tool to analyze the performance of yourapplication
    and construct fetch groups for different use-cases (businessoperations). No
    change to the code is necessary.
    Here is an example:
    CODE
    pm.beginUseCase("com.peacetech.sales.displayOrder");
    POClass o = (POClass)pm.getObjectById(oid, true);
    .... other JDO code ....
    pm.endUseCase();
    The meta data for the use-case will specify the fetch group to use when
    looking up the instance (and locking behaviour etc.). Other use-casescan
    have different settings. Only the being/end calls are needed in the codeto
    make this happen.
    Note that this is a very long way from being finalized. I have just madeup
    this example and how it works in JDO 2.0 is likely to be different.
    Use-case support will show up in JDO Genie beta releases soon. Wealready
    have powerful performance monitoring and analysis support in our GUI
    Workbench and very flexible fetch groups.
    Cheers
    David
    Here's my opinion
    David,
    Thank you for your response. Multiple fetch groups do give moreflexibility
    (I do not believe Kodo supports it though) but does not alter myposition
    >>
    I do not want to pollute my metadata with tons of fetch groups creating
    dependencies between my code and those fetch groups. JDOQL languagebeing
    what it is already creates unavoidable dependency between field namesfilter
    strings so I want to keep it the same way with other things which are
    essentially references to persistent fields (Disconnected instancesdepth
    control, Eagar fetching ....)
    As for polluting my code. I want to assure you everything configurablewill
    not be in my code but in JNDI or config files. As long as JDO givesclear
    API for expressing graph path selection
    Use case concept ties nicely with Graph Path selection concept. In factthis
    GraphPaths class along with some additional options is your use case.
    It is much easer for me to refactor and keep in sync field names and my
    GraphPath than fetch groups.
    Alex
    "Abe White" <[email protected]> wrote in message
    news:[email protected]...
    I think the basic idea you've suggested is a good one. We'll certainly
    consider it for a future release. The JDO 2 spec team is also
    pondering
    these problems...
    Marc Prud'hommeaux [email protected]
    SolarMetric Inc. http://www.solarmetric.com

  • BUG Can not set DML Fetch Mode:

    http://screencast.com/t/m7lEYZ1m5F
    while creating a DML ( Automatic Row Processing ) , can not set value of radio button .
    is this a bug , or i am missing something?

    >
    When you have a problem you'll get a faster, more effective response by including as much relevant information as possible upfront. This should include:
    <li>Full APEX version
    <li>Full DB/version/edition/host OS
    <li>Web server architecture (EPG, OHS or APEX listener/host OS)
    <li>Browser(s) and version(s) used
    <li>Theme
    <li>Template(s)
    <li>Region/item type(s) (making particular distinction as to whether a "report" is a standard report, an interactive report, or in fact an "updateable report" (i.e. a tabular form)
    It's even more essential to include full version information if you suspect a bug. Knowing the versions involved enables Oracle and other forum members to try to replicate the problem properly. It also allows us to look at the documentation or MOS bug database to compare the problem to known bugs and fixes.
    http://screencast.com/t/m7lEYZ1m5FYou've even managed to crop the screenshot so it doesn't show the version number...
    while creating a DML ( Automatic Row Processing ) , can not set value of radio button .
    is this a bug , or i am missing something?Confirmed as appearing in ARP (DML) processes in APEX 4.2.1.00.08. This does indeed appear to be a bug. However it is only cosmetic. DML Fetch Mode is an ARF (fetch) process option that is deprecated in APEX 4.x. Setting it for ARP (DML) processes is unnecessary, so you can safely ignore it.
    The appearance of the radio group in ARF processes is subject to a bug in APEX 4.2.0: +{message:id=10713985}+
    However it should not be appearing in an ARP (DML) definition at all as it was only an option for fetch behaviour.

  • Eager Fetching recursivity bug

    I have two classes A and B.
    A has two relations to B.
    A.theB1 (A 1-1 to B)
    A.theB2 (A 1-n to B)
    B has two relation to A.
    B.theA1 (B 1-n to A)
    B.theA2 (B 1-n to A)
    If I configure A.theB1 and A.theB2 with default-fetch-group="true".
    And then I Use Eager Fetching multiple:everything works fine.
    But if I also configure B.theA1 and B.theA2 with
    default-fetch-group="true".
    And then I Use Eager Fetching multiple
    I get this Exception:
    java.lang.StackOverflowError
         at java.util.TreeMap.access$400(TreeMap.java:77)
         at java.util.TreeMap$EntryIterator.nextEntry(TreeMap.java:1024)
         at java.util.TreeMap$KeyIterator.next(TreeMap.java:1047)
         at java.util.TreeMap.buildFromSorted(TreeMap.java:1588)
         at java.util.TreeMap.buildFromSorted(TreeMap.java:1576)
         at java.util.TreeMap.buildFromSorted(TreeMap.java:1534)
         at java.util.TreeMap.addAllForTreeSet(TreeMap.java:1492)
         at java.util.TreeSet.addAll(TreeSet.java:247)
         at kodo.jdbc.sql.AbstractSelect$JoinSet.<init>(AbstractSelect.java:1021)
         at kodo.jdbc.sql.AbstractSelect.and(AbstractSelect.java:719)
         at kodo.jdbc.sql.AbstractSelect.getJoins(AbstractSelect.java:541)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:229)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:221)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:874)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectMappings(JDBCStoreManager.java:835)
         at kodo.jdbc.runtime.JDBCStoreManager.access$000(JDBCStoreManager.java:30)
         at
    kodo.jdbc.runtime.JDBCStoreManager$SelectImpl.selectInternal(JDBCStoreManager.java:1071)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:259)
         at
    kodo.jdbc.meta.OneToOneFieldMapping.select(OneToOneFieldMapping.java:452)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:909)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectMappings(JDBCStoreManager.java:835)
         at kodo.jdbc.runtime.JDBCStoreManager.access$000(JDBCStoreManager.java:30)
         at
    kodo.jdbc.runtime.JDBCStoreManager$SelectImpl.selectInternal(JDBCStoreManager.java:1071)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:259)
         at
    kodo.jdbc.meta.OneToOneFieldMapping.select(OneToOneFieldMapping.java:452)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:909)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectMappings(JDBCStoreManager.java:835)
         at kodo.jdbc.runtime.JDBCStoreManager.access$000(JDBCStoreManager.java:30)
         at
    kodo.jdbc.runtime.JDBCStoreManager$SelectImpl.selectInternal(JDBCStoreManager.java:1071)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:259)
         at
    kodo.jdbc.meta.ManyToManyFieldMapping.load(ManyToManyFieldMapping.java:350)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:427)
         at
    kodo.runtime.DelegatingStoreManager.load(DelegatingStoreManager.java:141)
         at
    kodo.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:386)
         at
    kodo.runtime.DelegatingStoreManager.load(DelegatingStoreManager.java:141)
         at kodo.runtime.ROPStoreManager.load(ROPStoreManager.java:82)
         at kodo.runtime.StateManagerImpl.loadFields(StateManagerImpl.java:2274)
         at kodo.runtime.StateManagerImpl.load(StateManagerImpl.java:139)
         at
    kodo.runtime.PersistenceManagerImpl.load(PersistenceManagerImpl.java:2408)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1244)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1175)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:677)
         at kodo.jdbc.meta.OneToOneFieldMapping.load(OneToOneFieldMapping.java:481)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:731)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:720)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:720)
         at
    kodo.jdbc.runtime.JDBCStoreManager.initialize(JDBCStoreManager.java:338)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at
    kodo.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:340)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at kodo.runtime.ROPStoreManager.initialize(ROPStoreManager.java:57)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1240)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1175)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:677)
         at kodo.jdbc.meta.OneToOneFieldMapping.load(OneToOneFieldMapping.java:481)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:731)
         at
    kodo.jdbc.runtime.JDBCStoreManager.initialize(JDBCStoreManager.java:338)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at
    kodo.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:340)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at kodo.runtime.ROPStoreManager.initialize(ROPStoreManager.java:57)
    I have test every combination and what I see ,is that the Exception comes
    because "Eager Fetching" process works recursively.
    I remmember the same problem with Top Link Batch Reading.
    I don't know if this could help: but I see two solutions.
    1) explicity option to work recursively or not.
    2) limitate depth level of recursivity.
    This is the configuration file:
    javax.jdo.PersistenceManagerFactoryClass:
    kodo.jdbc.runtime.JDBCPersistenceManagerFactory
    javax.jdo.option.ConnectionDriverName: com.jnetdirect.jsql.JSQLDriver
    javax.jdo.option.ConnectionUserName: sa
    javax.jdo.option.ConnectionPassword:
    javax.jdo.option.ConnectionURL:
    jdbc:JSQLConnect://agarcia/database=kodo3/SelectMethod=cursor
    javax.jdo.option.Optimistic: true
    javax.jdo.option.RetainValues: true
    javax.jdo.option.NontransactionalRead: false
    kodo.ConnectionFactoryProperties: MaxCachedStatements=0
    kodo.DataCacheClass: kodo.datacache.CacheImpl
    kodo.DataCacheProperties: CacheSize=1000000
    kodo.PersistenceManagerClass: kodo.runtime.PersistenceManagerImpl
    kodo.QueryCacheProperties: CacheSize=10000
    kodo.RemoteCommitProviderClass: kodo.event.SingleJVMRemoteCommitProvider
    kodo.jdbc.DBDictionaryClass=kodo.jdbc.sql.SQLServerDictionary
    kodo.jdbc.TransactionIsolation=
    javax.jdo.option.Multithreaded: true
    ## Transaction ###
    kodo.TransactionMode: managed
    kodo.ManagedRuntimeClass: kodo.ee.JNDIManagedRuntime
    kodo.ManagedRuntimeProperties:
    TransactionManagerName=java:/TransactionManager
    #kodo.jdbc.MappingFactoryClass: kodo.jdbc.meta.MetaDataMappingFactory
    kodo.jdbc.DBDictionaryProperties: BatchLimit=0 JoinSyntax=sql92
    kodo.EagerFetchMode: multiple
    kodo.FetchBatchSize: 10000
    kodo.FetchThreshold: -1

    Oh boy. Oops.
    Thanks for the report.
    -Patrick
    On Fri, 01 Aug 2003 16:57:52 +0000, oscar wrote:
    >
    I have two classes A and B.
    A has two relations to B.
    A.theB1 (A 1-1 to B)
    A.theB2 (A 1-n to B)
    B has two relation to A.
    B.theA1 (B 1-n to A)
    B.theA2 (B 1-n to A)
    If I configure A.theB1 and A.theB2 with default-fetch-group="true".
    And then I Use Eager Fetching multiple:everything works fine.
    But if I also configure B.theA1 and B.theA2 with
    default-fetch-group="true".
    And then I Use Eager Fetching multiple
    I get this Exception:
    java.lang.StackOverflowError
         at java.util.TreeMap.access$400(TreeMap.java:77)
         at java.util.TreeMap$EntryIterator.nextEntry(TreeMap.java:1024)
         at java.util.TreeMap$KeyIterator.next(TreeMap.java:1047)
         at java.util.TreeMap.buildFromSorted(TreeMap.java:1588)
         at java.util.TreeMap.buildFromSorted(TreeMap.java:1576)
         at java.util.TreeMap.buildFromSorted(TreeMap.java:1534)
         at java.util.TreeMap.addAllForTreeSet(TreeMap.java:1492)
         at java.util.TreeSet.addAll(TreeSet.java:247)
         at kodo.jdbc.sql.AbstractSelect$JoinSet.<init>(AbstractSelect.java:1021)
         at kodo.jdbc.sql.AbstractSelect.and(AbstractSelect.java:719)
         at kodo.jdbc.sql.AbstractSelect.getJoins(AbstractSelect.java:541)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:229)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:221)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:874)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectMappings(JDBCStoreManager.java:835)
         at kodo.jdbc.runtime.JDBCStoreManager.access$000(JDBCStoreManager.java:30)
         at
    kodo.jdbc.runtime.JDBCStoreManager$SelectImpl.selectInternal(JDBCStoreManager.java:1071)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:259)
         at
    kodo.jdbc.meta.OneToOneFieldMapping.select(OneToOneFieldMapping.java:452)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:909)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectMappings(JDBCStoreManager.java:835)
         at kodo.jdbc.runtime.JDBCStoreManager.access$000(JDBCStoreManager.java:30)
         at
    kodo.jdbc.runtime.JDBCStoreManager$SelectImpl.selectInternal(JDBCStoreManager.java:1071)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:259)
         at
    kodo.jdbc.meta.OneToOneFieldMapping.select(OneToOneFieldMapping.java:452)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectBaseMappings(JDBCStoreManager.java:909)
         at
    kodo.jdbc.runtime.JDBCStoreManager.selectMappings(JDBCStoreManager.java:835)
         at kodo.jdbc.runtime.JDBCStoreManager.access$000(JDBCStoreManager.java:30)
         at
    kodo.jdbc.runtime.JDBCStoreManager$SelectImpl.selectInternal(JDBCStoreManager.java:1071)
         at kodo.jdbc.sql.AbstractSelect.select(AbstractSelect.java:259)
         at
    kodo.jdbc.meta.ManyToManyFieldMapping.load(ManyToManyFieldMapping.java:350)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:427)
         at
    kodo.runtime.DelegatingStoreManager.load(DelegatingStoreManager.java:141)
         at
    kodo.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:386)
         at
    kodo.runtime.DelegatingStoreManager.load(DelegatingStoreManager.java:141)
         at kodo.runtime.ROPStoreManager.load(ROPStoreManager.java:82)
         at kodo.runtime.StateManagerImpl.loadFields(StateManagerImpl.java:2274)
         at kodo.runtime.StateManagerImpl.load(StateManagerImpl.java:139)
         at
    kodo.runtime.PersistenceManagerImpl.load(PersistenceManagerImpl.java:2408)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1244)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1175)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:677)
         at kodo.jdbc.meta.OneToOneFieldMapping.load(OneToOneFieldMapping.java:481)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:731)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:720)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:720)
         at
    kodo.jdbc.runtime.JDBCStoreManager.initialize(JDBCStoreManager.java:338)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at
    kodo.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:340)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at kodo.runtime.ROPStoreManager.initialize(ROPStoreManager.java:57)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1240)
         at
    kodo.runtime.PersistenceManagerImpl.getObjectById(PersistenceManagerImpl.java:1175)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:677)
         at kodo.jdbc.meta.OneToOneFieldMapping.load(OneToOneFieldMapping.java:481)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:731)
         at
    kodo.jdbc.runtime.JDBCStoreManager.initialize(JDBCStoreManager.java:338)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at
    kodo.datacache.DataCacheStoreManager.initialize(DataCacheStoreManager.java:340)
         at
    kodo.runtime.DelegatingStoreManager.initialize(DelegatingStoreManager.java:134)
         at kodo.runtime.ROPStoreManager.initialize(ROPStoreManager.java:57)
    I have test every combination and what I see ,is that the Exception comes
    because "Eager Fetching" process works recursively.
    I remmember the same problem with Top Link Batch Reading.
    I don't know if this could help: but I see two solutions.
    1) explicity option to work recursively or not.
    2) limitate depth level of recursivity.
    This is the configuration file:
    javax.jdo.PersistenceManagerFactoryClass:
    kodo.jdbc.runtime.JDBCPersistenceManagerFactory
    javax.jdo.option.ConnectionDriverName: com.jnetdirect.jsql.JSQLDriver
    javax.jdo.option.ConnectionUserName: sa
    javax.jdo.option.ConnectionPassword:
    javax.jdo.option.ConnectionURL:
    jdbc:JSQLConnect://agarcia/database=kodo3/SelectMethod=cursor
    javax.jdo.option.Optimistic: true
    javax.jdo.option.RetainValues: true
    javax.jdo.option.NontransactionalRead: false
    kodo.ConnectionFactoryProperties: MaxCachedStatements=0
    kodo.DataCacheClass: kodo.datacache.CacheImpl
    kodo.DataCacheProperties: CacheSize=1000000
    kodo.PersistenceManagerClass: kodo.runtime.PersistenceManagerImpl
    kodo.QueryCacheProperties: CacheSize=10000
    kodo.RemoteCommitProviderClass: kodo.event.SingleJVMRemoteCommitProvider
    kodo.jdbc.DBDictionaryClass=kodo.jdbc.sql.SQLServerDictionary
    kodo.jdbc.TransactionIsolation=
    javax.jdo.option.Multithreaded: true
    ## Transaction ###
    kodo.TransactionMode: managed
    kodo.ManagedRuntimeClass: kodo.ee.JNDIManagedRuntime
    kodo.ManagedRuntimeProperties:
    TransactionManagerName=java:/TransactionManager
    #kodo.jdbc.MappingFactoryClass: kodo.jdbc.meta.MetaDataMappingFactory
    kodo.jdbc.DBDictionaryProperties: BatchLimit=0 JoinSyntax=sql92
    kodo.EagerFetchMode: multiple
    kodo.FetchBatchSize: 10000
    kodo.FetchThreshold: -1--
    Patrick Linskey
    SolarMetric Inc.

  • UrlIview Fetch Mode (POST /GET)

    Hi ,
    before i need shortly explain the activity:
    I am using a UrlIview to a extern businness web application.
    This web application is connecting by redirect to a shopping system where user can search and order items. The Basket of the shopping system is POST-back to the web application. In the POST-back Url (Hook Url) i trying to access the Iview by QuickLink like this:
    "http://[host]:[port]/irj/portal/[quickLink]?para1=value1&param2=value2"
    The first Problem is that i am don´t arrive my Iview when the Basket is send back by POST i am allwas getting the start page of my Portal. It seems that the Portal did not realized the POST
    The second Problem: In the shopping system there is an logg off button which send a GET to my Hook Url.
    -If my iview is using Request-Method GET and Fetch Mode Client-Side i arrive my Iview and the Session is OK.
    -If my iview is using Request-Method POST and Fetch Mode Server-Side i arrive my Iview but the web application cant get the session. How you sure can introduce the user cant´t go on without session
    Does anybody has a idea how to resolve this? So that i can access my iview by POST and also getting the right session?

    "http://host:port/irj/portal/quickLink?para1=value1&param2=value2"
    looks like a GET, not a POST. As a quiklink it will try to start the iView that has the quicklink quickLink. This will only happen if the iView is part of a role that belongs to the current portal user - it can't be used to start an arbitrary iView.
    Why are you using the portal as the hookUrl? Why not just start the correct web application in your AS Java?

  • Eager Fetch  question

    Hi,
    I am using eager fetch in Kodo 3.1.3 but not sure if my configuration is
    correct.
    I have a Report object which contains a collection of Memos objects. It
    is a 1-to-many relationship. After configure the kodo.properties and the
    mapping file as following:
    kodo.properties:
    Add the following line
    kodo.EagerFetchMode: multiple
    kodo.Log: SQL=TRACE
    In mapping jdo:
    <class name="Report" objectid-class="ReportId">
    <field name="memo" default-fetch-group="true">
    <collection element-type="Memo"/>
    </field>
    <field name="policyId" primary-key="true"/>
    </class>
    After making those changes, running my application against the database
    with say 100 reports, the SQL trace still showing 100 SQL statement rather
    than 1 single SELECT as I understand, ie. select all 100 reports and all
    associated memos in one visit to the db server.
    Please correct me if I am worng. Thanks.
    Cheers,
    Dien

    Hi,
    I am using eager fetch in Kodo 3.1.3 but not sure if my configuration is
    correct.
    I have a Report object which contains a collection of Memos objects. It
    is a 1-to-many relationship. After configure the kodo.properties and the
    mapping file as following:
    kodo.properties:
    Add the following line
    kodo.EagerFetchMode: multiple
    kodo.Log: SQL=TRACE
    In mapping jdo:
    <class name="Report" objectid-class="ReportId">
    <field name="memo" default-fetch-group="true">
    <collection element-type="Memo"/>
    </field>
    <field name="policyId" primary-key="true"/>
    </class>
    After making those changes, running my application against the database
    with say 100 reports, the SQL trace still showing 100 SQL statement rather
    than 1 single SELECT as I understand, ie. select all 100 reports and all
    associated memos in one visit to the db server.
    Please correct me if I am worng. Thanks.
    Cheers,
    Dien

  • SQL Developer  3.2.09 fetch rows limit

    Hi,
    I have a problem. When I perform a query on some table that returns a lot of rows I can get only number of rows that set in fetch size in Preferences->database->Advanced. It just stops and doesn't allow to scroll any more. There was no such kind of problems in previous release

    Found duplicate report here:No more than 50 records in a query result . Resolved.
    Edited by: user12009569 on 20.09.2012 3:20

  • Kiosk mode limit

    I have approximately 25 Sun Rays, and after the first 10 start and assume a kiosk session, the others will not and indicate there are no more sessions available. I've been all through the VDI and Sun Ray docs, but don't see a way to increase the number of kiosk/CAM sessions. Any recommendations?

    Well Dirk, I needed more than 10 sessions, but didn't require HA. Production installs require more systems, and it just wasn't valuable to my environment. I need my systems for running desktop sessions. This was for a temporary setup to run some classes using the infrastructure.
    I did find that /opt/SUNWkio/bin/kioskuseradm has an "extend" subcommand which would do what I needed to do... but...
    The evaluation installer installed users utku0-9 with uid 15000-150009, and then installed the vdadb user with uid 15010. The kioskuseradm command refused to extend things since the next uid was taken. I had to change the uid of the vdadb user, then go about finding the files and changing their ownership, then extend with kioskuseradm extend -c <additional count>

  • Mail gets locked into fetch mode and spins and spins and spins

    Since upgrading to Snow Leopard I have found that every now and then one of my mail accounts, sometimes two, stays stuck with the spinning collect mail thing. The only way I can stop it is to send myself a mail to that account; its arrival being the firm boot applied to bring it to its senses. Anyone else getting this?

    I changed my mail host and the problem went away, so I am forced to wonder if it was an entirely external problem.

  • ORA-01002/ Fetch out of sequence on lazy loading

    Hello,
    We are facing an oracle SQLException (ORA-01002: fetch out of sequence)
    while we are trying to get a field (retrieved via lazy loading) from an
    object that was retrieved using a kodoquery.
    This error only occurs during performance testing under a heavy load.
    (100 concurrent users). For each thread we get a new persistencemanager
    from the factory. And we have put the multithreaded option to true.
    Can anyone help us with this problem?
    Thanks in advance,
    Kind Regards,
    Niels Soeffers
    Caused by: java.sql.SQLException: ORA-01002: fetch out of sequence
         at
    oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
         at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
         at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
         at
    oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
         at
    oracle.jdbc.driver.T4CPreparedStatement.fetch(T4CPreparedStatement.java:1027)
         at
    oracle.jdbc.driver.OracleResultSetImpl.close_or_fetch_from_next(OracleResultSetImpl.java:291)
         at
    oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:213)
         at
    com.solarmetric.jdbc.DelegatingResultSet.next(DelegatingResultSet.java:97)
         at kodo.jdbc.sql.ResultSetResult.nextInternal(ResultSetResult.java:151)
         at kodo.jdbc.sql.AbstractResult.next(AbstractResult.java:123)
         at kodo.jdbc.sql.Select$SelectResult.next(Select.java:2236)
         at
    kodo.jdbc.meta.AbstractCollectionFieldMapping.load(AbstractCollectionFieldMapping.java:592)
         at kodo.jdbc.runtime.JDBCStoreManager.load(JDBCStoreManager.java:521)
         at
    kodo.runtime.DelegatingStoreManager.load(DelegatingStoreManager.java:133)
         at kodo.runtime.ROPStoreManager.load(ROPStoreManager.java:79)
         at kodo.runtime.StateManagerImpl.loadFields(StateManagerImpl.java:3166)
         at kodo.runtime.StateManagerImpl.loadField(StateManagerImpl.java:3265)
         at kodo.runtime.StateManagerImpl.isLoaded(StateManagerImpl.java:1386)
         at
    com.ardatis.ventouris.domain.OntvangstReeks.jdoGetontvangstTransacties(OntvangstReeks.java)
         at
    com.ardatis.ventouris.domain.OntvangstReeks.getStatus(OntvangstReeks.java:72)
         at
    com.ardatis.ventouris.service.financien.transfer.FinancienTOAssembler.getOntvangstReeksBaseTO(FinancienTOAssembler.java:71)
         at
    com.ardatis.ventouris.service.financien.transfer.FinancienTOAssembler.getOntvangstReeksBaseTOs(FinancienTOAssembler.java:84)
         at
    com.ardatis.ventouris.service.financien.FinancienManagerImpl.getOntvangstReeksBaseTOs(FinancienManagerImpl.java:241)
         at
    com.ardatis.ventouris.service.financien.ejb.FinancienManagerBean.getOntvangstReeksBaseTOs(FinancienManagerBean.java:62)
         at sun.reflect.GeneratedMethodAccessor181.invoke(Unknown Source)
         at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at com.sun.enterprise.security.SecurityUtil$2.run(SecurityUtil.java:153)
         at java.security.AccessController.doPrivileged(Native Method)
         at
    com.sun.enterprise.security.application.EJBSecurityManager.doAsPrivileged(EJBSecurityManager.java:950)
         at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:158)
         at
    com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:128)
         at $Proxy31.getOntvangstReeksBaseTOs(Unknown Source)
         at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
         at
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
         at java.lang.reflect.Method.invoke(Method.java:585)
         at
    com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(ReflectiveTie.java:123)

    We are using Oracle 10g and have tried multiple dirvers. (classes12.jar,
    ojdbc14.jar)
    Our kodo.properties ( actually the ra.xml we supply with the kodo.rar )
    <connector>
    <display-name>KodoJDO</display-name>
    <description>Resource Adapter for integration of the Kodo Java Data
    Objects (JDO) implementation with J2EE 1.3 compliant managed
    environments</description>
    <vendor-name>Solarmetric, Inc.</vendor-name>
    <spec-version>1.0</spec-version>
    <eis-type>jdo</eis-type>
    <version>1.0</version>
    <license>
    <description>
    See http://www.solarmetric.com for terms and license conditions.
    </description>
    <license-required>true</license-required>
    </license>
    <resourceadapter>
         <managedconnectionfactory-class>kodo.jdbc.ee.JDBCManagedConnectionFactory</managedconnectionfactory-class>
    <connectionfactory-interface>javax.resource.cci.ConnectionFactory</connectionfactory-interface>
    <connectionfactory-impl-class>kodo.jdbc.ee.JDBCConnectionFactory</connectionfactory-impl-class>
    <connection-interface>javax.resource.cci.Connection</connection-interface>
    <connection-impl-class>kodo.runtime.PersistenceManagerImpl</connection-impl-class>
    <transaction-support>XATransaction</transaction-support>
    <config-property>
    <description>A comma-separated list of query aggregate listeners
    to add to the default list of extensions. Each listener must implement
    the kodo.jdbc.query.JDBCAggregateListener interface.</description>
    <config-property-name>AggregateListeners</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The kodo.jdbc.meta.ClassIndicator to use by default
    for new mappings. The class indicator is responsible for tracking the
    concrete class or subclass implemented by the object stored in each row of
    a table.</description>
    <config-property-name>ClassIndicator</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>in-class-name</config-property-value>
    </config-property>
    <config-property>
    <description>The kodo.util.ClassResolver implementation that
    should be used for JDO class resolution. Defaults to a JDO spec-compliant
    resolver.</description>
    <config-property-name>ClassResolver</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>spec</config-property-value>
    </config-property>
    <config-property>
    <description>Details about various compatibiity levels for the
    current environment.</description>
    <config-property-name>Compatibility</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>The class name of either the JDBC java.sql.Driver, or
    an instance of a javax.sql.DataSource to use to connect to the non-XA data
    source.</description>
    <config-property-name>Connection2DriverName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The password for the user specified in
    Connection2UserName</description>
    <config-property-name>Connection2Password</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of properties to be passed to
    the non-XA JDBC Driver when obtaining a Connection. Properties are of the
    form "key=value". If the given JDBC Driver class is a DataSource, these
    properties will be used to configure the bean properties of the
    DataSource. </description>
    <config-property-name>Connection2Properties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The URL for the non-XA data source.</description>
    <config-property-name>Connection2URL</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The username for the connection listed in
    Connection2URL.</description>
    <config-property-name>Connection2UserName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of
    com.solarmetric.jdbc.ConnectionDecorator implementations to install on all
    connection pools.</description>
    <config-property-name>ConnectionDecorators</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The class name of either the JDBC java.sql.Driver, or
    an instance of a javax.sql.DataSource to use to connect to the data
    source.</description>
    <config-property-name>ConnectionDriverName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The JNDI name of the connection factory to use for
    finding non-XA connections. If specified, this is the connection that
    will be used for obtaining sequence numbers.</description>
    <config-property-name>ConnectionFactory2Name</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
         <config-property-value>jdbc/VentourisNonXA</config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of properties used to
    configure the javax.sql.DataSource used as the non-XA ConnectionFactory.
    Each property should be of the form "key=value", where "key" is the name
    of some bean-like property of the data source.</description>
    <config-property-name>ConnectionFactory2Properties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The JNDI name of the connection factory to use for
    obtaining connections.</description>
    <config-property-name>ConnectionFactoryName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
         <config-property-value>jdbc/Ventouris</config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of properties used to
    configure the javax.sql.DataSource used as the ConnectionFactory. Each
    property should be of the form "key=value", where "key" is the name of
    some bean-like property of the data source.</description>
    <config-property-name>ConnectionFactoryProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The password for the user specified in
    ConnectionUserName</description>
    <config-property-name>ConnectionPassword</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of properties to be passed to
    the JDBC Driver when obtaining a Connection. Properties are of the form
    "key=value". If the given JDBC Driver class is a DataSource, these
    properties will be used to configure the bean properties of the
    DataSource. </description>
    <config-property-name>ConnectionProperties</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>This property dictates when PersistenceManagers will
    retain and release data store connections. Available options are
    "on-demand" for retaining a connection only during pessimistic
    transactions and data store operations, "transaction" for retaining a
    connection for the life of each transaction, or "persistence-manager" to
    indicate that a persistence manager should retain and reuse a single
    connection for its entire lifespan.</description>
    <config-property-name>ConnectionRetainMode</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>transaction</config-property-value>
    </config-property>
    <config-property>
    <description>The URL for the data source.</description>
    <config-property-name>ConnectionURL</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The username for the connection listed in
    ConnectionURL.</description>
    <config-property-name>ConnectionUserName</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>Set to true if you''d like Kodo to copy all object
    ids before returning them to your code. If you do not plan on modifying
    identity objects, you can set this property to false to avoid the copying
    overhead.</description>
    <config-property-name>CopyObjectIds</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to cache data loaded from the data store.
    Must implement kodo.datacache.DataCache.</description>
    <config-property-name>DataCache</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The number of milliseconds that data in the data
    cache is valid for. A value of 0 or less means that by default, cached
    data does not time out.</description>
    <config-property-name>DataCacheTimeout</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>-1</config-property-value>
    </config-property>
    <config-property>
    <description>The type of data source in use. Available options
    are "local" for a standard data source under Kodo''s control, or
    "enlisted" for a data source managed by an application server and
    automatically enlisted in global transactions.</description>
    <config-property-name>DataSourceMode</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>enlisted</config-property-value>
    </config-property>
    <config-property>
    <description>The kodo.jdbc.sql.DBDictionary to use for database
    interaction. This is auto-detected based on the setting of
    javax.jdo.option.ConnectionURL, so you need only set this to override the
    default with your own custom dictionary or if you are using an
    unrecognized driver.</description>
    <config-property-name>DBDictionary</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>Whether to dynamically create custom structs to hold
    and transfer persistent state in the Kodo data cache and remote
    persistence manager frameworks. Dynamic structs can reduce data cache
    memory consumption, reduce the amount of data serialized back and forth
    under remote persistence managers, and improve the overall performance of
    these systems. However, they increase application warm-up time while the
    custom classes are generated and loaded into the JVM. Set to true to
    enable dynamic data structs.</description>
    <config-property-name>DynamicDataStructs</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>Specifies the default eager fetch mode to use.
    Either "none" to never eagerly-load relations, "join" for selecting 1-1
    relations along with the target object using inner or outer joins, or
    "parallel" for selecting 1-1 relations via joins, and collections
    (including to-many relations) along with the target object using separate
    select statements executed in parallel.</description>
    <config-property-name>EagerFetchMode</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>parallel</config-property-value>
    </config-property>
    <config-property>
    <description>The number of rows that will be pre-fetched when an
    element in a Query result is accessed. Use -1 to pre-fetch all
    results.</description>
    <config-property-name>FetchBatchSize</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>-1</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the JDBC fetch direction to use.
    Standard values are "forward", "reverse", and "unknown".</description>
    <config-property-name>FetchDirection</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>forward</config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of fetch group names that
    PersistenceManagers will load by default when loading data from the data
    store.</description>
    <config-property-name>FetchGroups</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of query filter listeners to
    add to the default list of extensions. Each listener must implement the
    kodo.jdbc.query.JDBCFilterListener interface.</description>
    <config-property-name>FilterListeners</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>Whether or not Kodo should automatically flush
    modifications to the data store before executing queries.</description>
    <config-property-name>FlushBeforeQueries</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>with-connection</config-property-value>
    </config-property>
    <config-property>
    <description>If true, Kodo will order all SQL inserts, updates,
    and deletes to meet your schema''s foreign key constraints. Defaults to
    false.</description>
    <config-property-name>ForeignKeyConstraints</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>If false, then the JDO implementation must consider
    modifications, deletions, and additions in the PersistenceManager
    transaction cache when executing a query inside a transaction. Else, the
    implementation is free to ignore the cache and execute the query directly
    against the data store.</description>
    <config-property-name>IgnoreCache</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to manage inverse relations during flush.
    Set to true to use the default inverse manager. Custom inverse managers
    must extend kodo.runtime.InverseManager.</description>
    <config-property-name>InverseManager</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of
    com.solarmetric.jdbc.JDBCListener implementations to install on all
    connection pools.</description>
    <config-property-name>JDBCListeners</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>The license key provided to you by SolarMetric. Keys
    are available at www.solarmetric.com</description>
    <config-property-name>LicenseKey</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value><KEY-REMOVED></config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to handle acquiring locks on persistent
    instances. Must implement kodo.runtime.LockManager.</description>
    <config-property-name>LockManager</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>pessimistic</config-property-value>
    </config-property>
    <config-property>
    <description>The number of milliseconds to wait for an object lock
    before throwing an exception, or -1 for no limit.</description>
    <config-property-name>LockTimeout</config-property-name>
    <config-property-type>java.lang.Integer</config-property-type>
    <config-property-value>-1</config-property-value>
    </config-property>
    <config-property>
    <description>LogFactory and configuration for Kodo''s logging
    needs.</description>
    <config-property-name>Log</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>kodo(DefaultLevel=WARN, Tool=WARN,
    Runtime=WARN, SQL=WARN)</config-property-value>
    </config-property>
    <config-property>
    <description>The mode to use for calculating the size of large
    result sets. Legal values are "unknown", "last", and "query".</description>
    <config-property-name>LRSSize</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>query</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to integrate with an external transaction
    manager. Must implement kodo.runtime.ManagedRuntime.</description>
    <config-property-name>ManagedRuntime</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>auto</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to configure management and profiling
    capabilities.</description>
    <config-property-name>ManagementConfiguration</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>none</config-property-value>
    </config-property>
    <config-property>
    <description>The kodo.jdbc.meta.MappingFactory that will provide
    the object-relational mapping information needed to map each persistent
    class to the database.</description>
    <config-property-name>MappingFactory</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>file</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to create metadata about persistent
    types. Must implement kodo.meta.MetaDataLoader</description>
    <config-property-name>MetaDataLoader</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>jdo</config-property-value>
    </config-property>
    <config-property>
    <description>If true, then the application plans to have multiple
    threads simultaneously accessing a single PersistenceManager, so measures
    must be taken to ensure that the implementation is thread-safe. Otherwise,
    the implementation need not address thread safety.</description>
    <config-property-name>Multithreaded</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>If true, then it is possible to read persistent data
    outside the context of a transaction. Otherwise, a transaction must be in
    progress in order read data.</description>
    <config-property-name>NontransactionalRead</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>If true, then it is possible to write to fields of a
    persistent-nontransactional object when a transaction is not in progress.
    If false, such a write will result in a JDOUserException.</description>
    <config-property-name>NontransactionalWrite</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>Determines the persistence manager's behavior in
    calls to getObjectById with a validate parameter of false. Use "check" to
    check that a database record exists for the object and load its fetch
    group fields. Use "hollow" to return a hollow instance.</description>
    <config-property-name>ObjectLookupMode</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>check</config-property-value>
    </config-property>
    <config-property>
    <description>Selects between optimistic and pessimistic (data
    store) transactional modes.</description>
    <config-property-name>Optimistic</config-property-name>
    <config-property-type>java.lang.Boolean</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>Action to take when Kodo discovers an orphaned key in
    the database. May be a custom action implementing
    kodo.event.OrphanedKeyAction.</description>
    <config-property-name>OrphanedKeyAction</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>log</config-property-value>
    </config-property>
    <config-property>
    <description>The name of the concrete implementation of
    javax.jdo.PersistenceManagerFactory that
    javax.jdo.JDOHelper.getPersistenceManagerFactory () should create. For
    Kodo JDO, this should be kodo.jdbc.runtime.JDBCPersistenceManagerFactory
    or a custom extension of this type.</description>
    <config-property-name>PersistenceManagerFactoryClass</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>kodo.jdbc.runtime.JDBCPersistenceManagerFactory</config-property-value>
    </config-property>
    <config-property>
    <description>Persistence manager plugin and properties. If you
    use a custom class, it must extend
    kodo.runtime.PersistenceManagerImpl.</description>
    <config-property-name>PersistenceManagerImpl</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>default</config-property-value>
    </config-property>
    <config-property>
    <description>Configure this persistence manager factory to service
    remote persistence managers.</description>
    <config-property-name>PersistenceManagerServer</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>false</config-property-value>
    </config-property>
    <config-property>
    <description>A comma-separated list of the class names of all
    persistent classes to register whenever a persistence manager is
    obtained.</description>
    <config-property-name>PersistentClasses</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>com.ardatis.ventouris.domain.KwartaalVerhoging,
    com.ardatis.ventouris.domain.Land, com.ardatis.ventouris.domain.Gemeente,
    com.ardatis.ventouris.domain.Adres,
    com.ardatis.ventouris.domain.ContactGegeven,
    com.ardatis.ventouris.domain.AdresContactGegeven,
    com.ardatis.ventouris.common.type.AdresType,
    com.ardatis.ventouris.domain.OntvangstTransactie,
    com.ardatis.ventouris.domain.OntvangstReeks,
    com.ardatis.ventouris.domain.Ontvangst,
    com.ardatis.ventouris.domain.Inkomen,
    com.ardatis.ventouris.domain.loopbaan.LoopbaanPeriode,
    com.ardatis.ventouris.common.type.InkomenSoort,
    com.ardatis.ventouris.common.type.INSZ,
    com.ardatis.ventouris.domain.Aangeslotene,
    com.ardatis.ventouris.domain.NatuurlijkePersoon,
    com.ardatis.ventouris.domain.Persoon, com.ardatis.ventouris.domain.Rol,
    com.ardatis.ventouris.domain.Dossier,
    com.ardatis.ventouris.common.type.Geslacht,
    com.ardatis.ventouris.common.type.Taal,
    com.ardatis.ventouris.common.type.Nationaliteit,
    com.ardatis.ventouris.common.type.KostType,
    com.ardatis.ventouris.domain.Verhoging,
    com.ardatis.ventouris.domain.Aanvraag,
    com.ardatis.ventouris.domain.AanvraagAansluitingSS,
    com.ardatis.ventouris.domain.AanvraagToestand,
    com.ardatis.ventouris.common.type.AanvraagToestandType,
    com.ardatis.ventouris.domain.Factuur,
    com.ardatis.ventouris.domain.TaakType, com.ardatis.ventouris.domain.Taak,
    com.ardatis.ventouris.domain.BijdrageBerekening,
    com.ardatis.ventouris.domain.calculationparameters.HerwaarderingsIndex,
    com.ardatis.ventouris.domain.integration.asis.TempInterneOntvangst,
    com.ardatis.ventouris.domain.calculationparameters.InkomenGrens,
    com.ardatis.ventouris.domain.calculationparameters.BijdrageCategorie,
    com.ardatis.ventouris.domain.calculationparameters.BijdrageCategorieGroep,
    com.ardatis.ventouris.domain.integration.asis.TempOntvangstKinderbijslag,
    com.ardatis.ventouris.domain.calculationparameters.JaarVerhogingParameter,
    com.ardatis.ventouris.domain.calculationparameters.KwartaalVerhogingParameter,
    com.ardatis.ventouris.domain.UitgaveReeks,
    com.ardatis.ventouris.domain.Uitgave,
    com.ardatis.ventouris.domain.Terugbetaling,
    com.ardatis.ventouris.domain.BedragTerugbetaald,
    com.ardatis.ventouris.domain.BijdrageSS</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to proxy second class object fields of
    managed instances. Must implement kodo.util.ProxyManager.</description>
    <config-property-name>ProxyManager</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>default</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to cache query results loaded from the
    data store. Must implement kodo.datacache.QueryCache.</description>
    <config-property-name>QueryCache</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to cache query compilation data. Must
    implement java.util.Map. Does not need to be thread-safe -- it will be
    wrapped via the Collections.synchronizedMap() method if it does not extend
    kodo.util.CacheMap.</description>
    <config-property-name>QueryCompilationCache</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>true</config-property-value>
    </config-property>
    <config-property>
    <description>The default lock level to use when loading objects
    within non-optimistic transactions. Set to none, read, write, or the
    numeric value of the desired lock level for your lock
    manager.</description>
    <config-property-name>ReadLockLevel</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value>read</config-property-value>
    </config-property>
    <config-property>
    <description>Plugin used to communicate commit information among
    JVMs. Must implement kodo.event.RemoteCommitProvider.</description>
    <config-property-name>RemoteCommitProvider</config-property-name>
    <config-property-type>java.lang.String</config-property-type>
    <config-property-value></config-property-value>
    </config-property>
    <config-property>
    <description>Whether or not RemoteCommitEvents will include the
    object Ids of objects added during the transaction.</description>
    <config-property-name>RemoteCommitTransmitAddObjectIds</config-property-na

  • SQL batch doesn't work; How to fetch related objects with fetch group?

    I have two questions:
    1. SQL Batch doesn't seem to work. I have tested some batch object creation
    with BatchLimit set to -1, 0, 1, 25, 100. They all have similar
    performance.
    kodo.jdbc.DBDictionary: BatchLimit=25
    2. How to use custom fetch group to fetch related objects? The example of
    custom fetch group only show how to fetch different attributes in different
    groups. I have a test cases where I would like to pre-fetch related objects
    to save round trip.
    Enviroments:
    * Kodo 3.1.0 RC1
    * Oracle 9i release 1
    Thanks for any help!
    Qingshan Luo
    Senior Software Engineer
    Open Harbor
    1123 Industrial Road
    San Carlos, CA 94070
    Phone: 650-413-4251
    Fax: 650-413-4298

    try poracle 10g driver. At least they fixed terrible CLOB bug may be batch
    to. BTW 9.2.x has problem with batching with deferred constraints so be
    careful
    "Greg Campbell" <[email protected]> wrote in message
    news:c3dmnu$rmj$[email protected]..
    >
    "Qingshan Luo" <[email protected]> wrote in message
    news:c3dg7q$mdl$[email protected]..
    Hi,
    I have two technical questions with Kodo.
    1. SQL Batch doesn't seem to work. I have tried batch size of -1, 0, 1,25.
    But the performance from batch creating objects is not affected by batch
    size.
    kodo.jdbc.DBDictionary: BatchLimit=25You may be running into a bug in the Oracle 9.2 driver. That driverdoesn't
    reliably give update counts when using batching and prepared statement
    caching. By default, Kodo will turn off batching. You can manuallyenable
    batching by setting the BatchLimit on your DBDictionary, as you've done.If
    you do this, though, you may want to turn off prepared statement cachingby
    setting MaxCachedStatements to 0 (see
    http://www.solarmetric.com/Software/Documentation/3.1.0RC1/docs/ref_guide_dbsetup.html#ref_guide_dbsetup_builtin).
    >
    2. How to use custom fetch groups to eagerly fetch related persistable
    objects? Example only showed attributes, not relationships.You can find information on setting up eager fetching of relations at
    http://www.solarmetric.com/Software/Documentation/3.0.3/docs/ref_guide_
    perfpack_eager.html
    Basically, you'll need to add the relations to your fetch group, and
    set the eager fetching mode.
    Enviroment:
    * Kodo 3.1.0 RC1
    * Oracle 9i release 1.
    Qingshan Luo
    Senior Software Engineer
    Open Harbor
    1123 Industrial Road
    San Carlos, CA 94070
    Phone: 650-413-4251
    Fax: 650-413-4298

Maybe you are looking for

  • My iPhone 5s Screen  is Completely Unresponsive

    I've read other issues with this, but none of them seem to sound quite like mine. I'm desperate for help right now!!!! My phone is still relatively new - got it in December of 2013. I have never dropped it or "injured" it in any way, no water damage,

  • How switch off Order Responce in MM-SUS

    Hello everyone, I was checking the documentation about MM-SUS and it always says that Order Response can be optional; however, when I send a PO from R/3 to SUS is always needed. Vendors have to confirm the PO in order to create the ASN. I tried chang

  • Formulas and Rounding

    Two things here that I've found problematic. -How can I set cells to display the formulas I have typed into them, rather than the formula outcome? -My Numbers is rounding 5s down, not up? Is this An American thing or a fault in Numbers? Anyone got an

  • Message and queue

    Hi, Iam not clear with the concept of message and queue in XI, can anybody please tell how the message and queue are related and what are the inbound and outbound queues? Thanks.

  • Activity in NWDI

    Hai every body, What is the purpose of Activity in NWDI environment ? Thanks, Namarata