Java Programming - Cheap Web Hosting Blog

Strings for supported B options The supportedOptions() method of a persistence manager factory returns a Collection of Strings. The presence of particular strings in that collection indicates support for the corresponding optional feature of the JDO specifica tion. In the same way, the absence of a string indicates that the corresponding feature is not supported by the implementation. The strings used for each optional feature are standardized by the JDO speci fication, and are listed here for quick reference. For further information, please refer to section 6.3.1 on page 104. “javax.jdo.option.TransientTransactional” “javax.jdo.option.NontransactionalRead” “javax.jdo.option.NontransactionalWrite” “javax.jdo.option.RetainValues” “javax.jdo.option.RestoreValues” “javax.jdo.option.Optimistic” “javax.jdo.option.ApplicationIdentity” “javax.jdo.option.DatastoreIdentity” “javax.jdo.option.NonDurableIdentity” “javax.jdo.option.ArrayList” “javax.jdo.option.HashMap” “javax.jdo.option.Hashtable” “javax.jdo.option.LinkedList” “javax.jdo.option.TreeMap” “javax.jdo.option.TreeSet” “javax.jdo.option.Vector” “javax.jdo.option.Map” “javax.jdo.option.List” “javax.jdo.option.Array” “javax.jdo.option.NullCollection” “javax.jdo.option.ChangeApplicationIdentity” “javax.jdo.query.JDOQL”
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services

Properties for A JDOHelper bootstrap The following are the standard property names for use when constructing a persistence manager factory through the following JDOHelper method: getPersistenceManagerFactory(Properties props) Each JDO vendor may add other properties for their implementation, which will be described in the product-specific documentation. For a detailed discussion of each of these properties please refer to the JDOHelper section in Chapter 6. javax.jdo.PersistenceManagerFactoryClass javax.jdo.option.Optimistic javax.jdo.option.RetainValues javax.jdo.option.RestoreValues javax.jdo.option.IgnoreCache javax.jdo.option.NontransactionalRead javax.jdo.option.NontransactionalWrite javax.jdo.option.Multithreaded javax.jdo.option.ConnectionDriverName javax.jdo.option.ConnectionUserName javax.jdo.option.ConnectionPassword javax.jdo.option.ConnectionURL javax.jdo.option.ConnectionFactoryName javax.jdo.option.ConnectionFactory2Name
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services

Sources of further information 221 13.2.1 Ogilvie Partners Ltd The author maintains a website which is dedicated to JDO: http://www.OgilviePartners.com Ogilvie Partners offer vendor-independent JDO consultancy, training, and mentoring. The website includes useful downloads such as FAQs and presentations on JDO which I have delivered at conferences and user groups worldwide. 13.2.2 JavaDataObjects at Yahoo!Groups The JavaDataObjects discussion forum at Yahoo!Groups is lively and enjoys contributions from many high-profile members of the JDO community: http://groups.yahoo.com/group/JavaDataObjects/ The moderators maintain a JDO suggestions document and the group regularly debates proposals for future inclusion in JDO. 13.2.3 JDOcentral.com If you prefer not to receive regular email but to go online for information about JDO, you should try JDOcentral. This comprehensive forum contains discussions about JDO as well as news from the community, a calendar of forthcoming JDO-related events, and other features. A newsletter is emailed monthly to subscribers. http://www.JDOcentral.com
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

220 Epilogue be employed on an as-required basis, although in most cases the default fetch group will remain adequate. In the interim, look to the JDO vendors to implement their own enhancements ahead of any standardization in this area. 13.1.5 Optimistic transactions Optimistic transactions are an optional feature of JDO 1.0, although this feature is under-specified, especially in the areas of isolation and failure recovery. In particular, there is no straightforward and portable way of discerning the instances for which optimistic concurrency assumptions have failed. Furthermore, the application remains responsible for refreshing all instances associated with failed optimistic transactions, a tedious task for which additional support should be provided. As users of JDO employ optimistic transactions and vendors provide proprietary enhancements to make the task easier, the JDO Expert Group will be working to standardize the necessary features. 13.1.6 Standardized O-R mapping JDO 1.0 does not state how the persistent fields of an instance are mapped to the rows and columns of pre-existing database schemas. This work is being undertaken independently by each RDBMS-based JDO vendor in order to achieve competitive superiority. In due course the description of these mappings may be standardized, which would improve the portability of such mappings between implementations. 13.1.7 Event-driven reactive instances Enterprise applications are making significant use of JMS for inter-component asynchronous communication. Increasingly, JMS is being employed in the business-to-business arena. The content of such messages typically needs to be persisted. A message-driven bean can be constricted that will persist incoming data through JDO. This was illustrated in Chapter 11. However, this approach mandates the presence of a J2EE application server. It is easy to conceptualize a JDO instance which itself reacts to incoming JMS messages, through a direct JMS/JDO connection which is independent of J2EE and the message-driven bean architecture. It will be interesting to see how JDO evolves in this area. 13.2 Sources of further information Further information about JDO is available in a number of online forums that are updated regularly.
Note: If you are looking for cheap and reliable provider to host and run your servlet application check Vision servlet hosting services

Beyond JDO 1.0 219 Or perhaps it would be useful to define a query and execute it in separate steps. This might even facilitate the chaining of query executions, illustrated below with a pipe | operator. DEFINE-QUERY q1 CANDIDATE com.ogilviepartners.jdobook.op.BusinessPartner IMPORTS com.ogilviepartners.jdobook.op.* VARIABLES Order o PARAMETERS Double searchValue FILTER customer.orders.contains(o) && o.totalValue > searchValue ORDERING name ascending; EXECUTE-QUERY q1 PARAMETER-VALUES 1000 | q2 PARAMETER-VALUES … ; Please note that the above is not supported, or even suggested syntax, but should be sufficient to give the reader an idea of the possibilities for a standard string-based JDOQL representation. 13.1.3.5 Query object model I have already pointed out that SQL suffers from loose typing and deferred compilation, which makes it easy to compile and deploy applications with syntactically incorrect queries. The current form of JDOQL reduces this risk significantly, since all mapping between JDO instances and the underlying data store is handled internally. However, it is still possible to write a query in JDOQL that will not execute correctly, but which will be compiled by the Java compiler. This is due to the presence of string elements within a programmatic query definition. JDOQL will not have its current string elements (variable declaration, filter, ordering declaration, parameter declaration, etc.) removed, as their presence enables a wide variety of dynamic applications. However, it is likely that a future specification of JDOQL will provide the classes and methods necessary to describe a query in a purely programmatic manner, with no reliance on string data. This is known as a query object model (QOM). In the interim, vendors will be quick to provide tools for the generation and verification of queries and query strings in JDOQL. 13.1.4 Pre-fetch patterns JDO currently defines the default fetch group. This is a grouping of fields which, in addition to primary key fields, will be retrieved from the data store when the instance is first read. However, it has been argued successfully that this simplistic treatment is inadequate in certain scenarios. It is possible that work in this area will provide application-level functionality for influencing the data that is initially retrieved for each instance. This functionality could then
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

218 Epilogue Imagine a situation where you have a collection of Orders and wish to identify each Product for which more than a designated quantity was ordered on a single OrderLine. Using JDOQL you can filter the original collection of orders to only those that contain individual OrderLines with more than the designated quantity. However, you then have to iterate through the returned collection of Orders, and each Orders collection of OrderLines, to programmatically locate the individual Product instances. This would be easier if a JDOQL query could take one candidate class (Order) and return a collection of a different class (Product) according to the filter criteria. Such functionality, referred to as projection, is expected in a future release. 13.1.3.2 Aggregates JDOQL does not define any aggregate functions (e.g. maximum, count, average, etc.). Queries to determine the maximum value of a persistent field, such as an order number, can be written to return the entire candidate collection in an appropriate sequence (e.g. by orderNumber descending). However, the definition of a maximum aggregate function would be far more flexible. Aggregates are expected in a future release. 13.1.3.3 Additional filter operators It is also likely that the filter operators will be complemented in due course with an operator equivalent to the Java keyword instanceof. This could be used to restrict the result of a query to certain subbranches of inheritance or implementation hierarchies. 13.1.3.4 String-based query definition It is already possible to define a query as a set of strings, as illustrated by the Dynamic Query Window presented in Chapter 8. However, there is no standard for a single string grammar encapsulating all query elements. If such a grammar is defined, JDO query monitors could be written that would accept, compile, and execute queries in this form. For example, the query shown in the Dynamic Query Window in Figure 8.2 (page 144) might be typed into a JDO query monitor as: EXECUTE-NEW-QUERY CANDIDATE com.ogilviepartners.jdobook.op.BusinessPartner IMPORTS com.ogilviepartners.jdobook.op.* VARIABLES Order o PARAMETERS Double searchValue FILTER customer.orders.contains(o) && o.totalValue > searchValue ORDERING name ascending PARAMETER-VALUES 1000;
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

Beyond JDO 1.0 217 13.1.2 Clarification of extent The JDO 1.0 API provides for the construction of extents that include or exclude subclasses. The construction of extents that do not include subclasses is intended to facilitate performance improvements within those JDO implementations that map to underlying relational databases. By knowing that subclasses are to be excluded, the implementation can reduce the number of table joins in SQL queries based on that extent. However, from an object oriented perspective, the concept of an extent that does not include subclasses is nonsensical. By definition, any instance of a subclass is ascribed the types of its superclass, and the Java instanceof operator will evaluate to true for each of them. Indeed, through its extensive support for polymorphism, Java itself does not recognize the notion of an instance of this class but not any of its subclasses. In the same way that the implementation of extents without subclasses can yield a performance improvement for RDBMS-based implementations, it can cause significant complications for ODBMS-based implementations. Finally, any application developer who employs extents without subclasses is making the assumption, perhaps unwisely, that there will never be any subclasses. This goes against the tenets of object oriented design. I believe that the notion of an extent without subclasses should be made a hint to the implementation. The implementation would be at liberty to include any instances of the extent s candidate class (even subclasses thereof). However, if it is beneficial in performance terms for the implementation to exclude subclasses, then it may do so. As such, extents without subclasses should be used only when it is known that no subclasses exist, and it is necessary to achieve the performance gains offered by a particular relational implementation. This would maintain the object oriented correctness of JDO and give RDBMS-based implementations every chance of improving performance, whilst not burdening ODBMS-based implementations with unnecessary complications. 13.1.3 JDOQL JDOQL holds the promise of being an efficient, vendor-neutral query language based on familiar Java syntax. Its restriction that only persistent fields may be accessed enables implementations to execute queries quickly. This is in contrast to true object query languages that require the instantiation of all candidate instances, many of which will fail the filter criteria before the filter can be evaluated. However, the JDOQL we have with JDO 1.0 is just a beginning, and I list below some of the areas where enhancements and new features can be expected. 13.1.3.1 Projection Presently JDOQL is only capable of returning a subset of the candidate collection or extent. If you give a query a collection of orders, it will return to you a subset of that collection you still get just orders.

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Virtualwebstudio jsp web hosting provider

Epilogue 13 13.1 Beyond JDO 1.0 The first 11 chapters discussed JDO 1.0 in detail. Chapter 12 illustrated how comprehensively the specification is being adopted and implemented by the various JDO vendors. In this final chapter I wish to discuss a few areas where further refinement and extension of JDO can be anticipated in the future. If you wish to contribute further ideas for enhancements or new features, an informal list is maintained by the moderators of the JavaDataObjects discussion forum at Yahoo!Groups (see 13.2.2). 13.1.1 Sequences Sequence objects have been provided by relational database implementations for many years. They provide mechanisms for obtaining a sequence of numbers, and are often used to populate primary key fields in top-level domain objects, e.g. order numbers, invoice numbers, etc. (Some existing RDBMS-based applications use sequences for the construction of internal Object IDs. This functionality is provided in JDO by the use of datastore identity.) JDO does not directly support sequence objects, but positions this as an issue to be solved by the domain object model. In the short term, JDO vendors may provide proprietary extensions by which sequence objects internal to the data store can be accessed. However, it is an area that is likely to be considered for specification as part of a future JDO release. Conceptually, sequences can be used in two ways. Used transactionally, a sequence is associated with the active transaction each time a new value is requested. This ensures that, in the case of transaction rollback, the sequence object will not actually have been altered. Such assurance is imperative when assigning numbers such as check numbers or invoice numbers, where auditors would not accept missing entries in the sequence. This usage does, however, reduce overall concurrency since access to each individual sequence represents a potential bottleneck in the application. Used non-transactionally, sequences do not become associated with transactions. When invoked they yield the next entry in the sequence, but are not affected by subsequent rollback events. This results in significantly higher concurrency, but is only appropriate when the occasional hole in the sequence is acceptable (e.g. for delivery numbers, which are not audited in the same way as invoice or check numbers).

Hint: If you are looking for high quality and reliable webspace provider to host and run your jsp hosting application check Virtualwebstudio jsp web hosting provider

PE:J The Productivity Environment for Java by HYWY Software 213 12.10.3 Product family 12.10.3.1 Orient ODBMS Just Edition The Just Edition works with a very small footprint (around 250Kb) and is perfect for embedded devices. 12.10.3.2 Orient ODBMS Enterprise Edition The Enterprise Edition supports complex architectures with thousands of clients in a distributed environment, with many enterprise features such as load- balancing, fault-tolerance, and data replication. 12.10.4 Supported data stores Orient ODBMS. 12.10.5 Supported application servers Orient integrates with any application server that runs on JDK 1.3 or above, e.g. BEA WebLogic Server, IBM WebSphere, JBoss, etc. 12.11 PE:J The Productivity Environment for Java by HYWY Software Contact addresses: www.hywy.com and sales@hywy.com PE:J and Productivity Environment are trademarks of HYWY Software Corporation. 12.11.1 About HYWY Software HYWY Software Corporation is a developer of Java productivity software. HYWY s products significantly reduce the complexity, cost, risk, and time-tomarket of Java development. HYWY is a Sun Developer Connection Commercial Developer, a Forte for Java Framework Extension Partner, and an IBM PartnerWorld member. 12.11.2 About PE:J The PE:J Productivity Environment for Java is the first environment to deliver an integrated, standards-based, platform-independent product solution to enhance and automate the complete Java technology productivity lifecycle; from the conceptualization of a business idea to object model to scripted Java code.
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

212 JDO implementations IBM DB2, Version 7.1 Informix Dynamic Server 2000, Version 9.20 Oracle 8i, Version 8.1.x Microsoft SQL Server 2000, Version 8.00.194 MySQL, Version 3.23.36 Sybase ASE, Version 11.9.2 Type mappings are exposed in an XML file, enabling users to add mappings for additional databases if required. 12.9.4 Supported application servers All J2EE 1.3-compliant application servers. Specific details are available upon request. 12.10 Orient by Orient Technologies Contact addresses: www.orientechnology.com and sales@orientechnology.com Orient is a trademark of Orient Technologies. 12.10.1 About Orient Technologies Orient Technologies provides solutions based on its own fast Object Database engine. Orient was one of the first products to support the ODMG 3.0 standard for ODBMS. A partially JDO-compliant implementation of the Orient ODBMS was first made available in mid-2001. Mr Luca Garulli, project leader for the Orient ODBMS products, is a member of the JDO Expert Group. 12.10.2 About Orient Orient is a 100% pure ODBMS. It supports worldwide standards as Sun JDO 1.0, ODMG 3.0, and SQL. Orient is a pure object database and was built upon object oriented concepts rather than the relational model (tables, columns, and rows). Its JDO implementation treats Java objects without conversion since Orient manages objects directly, instead of mapping them to table rows as would be the case for relational data stores. As a JDO implementation, Orient delivers high performance at low cost, when compared with alternative solutions comprising an object-relational JDO Implementation and a relational database.
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services