He JDO2.0 Plan starts
Recently, Xin Wen Sun officially joined JDOCENTRAL.com as one of its Charter Member, indicating that Sun's formal support and promotion of JDO. In the past, although Sun proposed JDO specification, it was always not enough in formal support. It feels like it is because it will impact its EJB system, so it has only been half-pushing to provide limited publicity, and the main promotion of JDO or JDOCENTRAL. CoM this public welfare website. But now, the JDO specification has been raised for nearly a year and a half, and there are many excellent products that have emerged, and it is about to form a new cyclone. SUN sees the opportunity to mature, then do not jump out, what to stay Time! So we are also very happy to see that Sun officially added JDOCENTRAL, and started the JDO2.0 program preparation. Source: http://www.theserverside.com/home/thread.jsp? Thread_id = 20875 & article_count = 37
We have already mentioned that JDO1.0 has already proposed a year and a half, but it seems that the public's acceptance is not enough, and there are not many application development companies to show enough enthusiasm. This is also related to the limitations of JDO1.0 except for the reasons for Sun's driving. We look forward to the development of the JDO1.0 to solve most of the small and medium-sized database applications, that is, can substitute JDBC, but do not support mapping and database statistics are the biggest defects of JDO1.0. I have been looking forward to JDO2.0 to solve these problems, at least a set of OPTIONAL APIs specifically for JDBC, which can also do not affect JDO applications in other types of databases (such as files, XML, and ODB, etc.). In general, JDO1.0 can meet most of our development database applications, just plus these features will be more convenient.
Let's take a look at what JDO2.0 will bring us. In fact, in the JDO1.0 specification, some features that have been concerned about most people have been put forward, but because the idea is not mature, or if you are inconsistent, there is still a further verification to practice, so I have to put it in JDO2. .0 to normalize. Therefore, we have reason to believe that the issues of JDO2.0 will first include these contents, at least most of the content will be included. Here, I briefly explain what is the topic push to the next version in the JDO1.0 specification:
Nested transaction support is a database that must be provided. However, in actual development, we often need multi-level transactions, and a failure of an operation in the middle will not cause rollback of the entire transaction, but just a small Some operations roll back and take additional operations. JDO2.0 will standardize this, of course, may be an optional feature, allowing vendors to choose whether it is implemented, but once implemented, the user can perform nested transaction processing through the specification API. For example, when we write business logic, there may be many logical methods, each method needs to update the data object, that is, a transaction is needed in the method. If one of the methods may be called by another method, then "transaction has begun" exception in JDO1.0, so we have to write every logical method with the following code to ensure that each of them Call no error: public void logicaloperation1 () {Transaction TX = Pm.currentTransAction (); boolean newtx =! Tx.isactive (); if (newTX) TX.BEGIN (); // Do some data objects update IF (newtx) tx.commit ();} In JDO2.0, we don't have to worry about this problem, and each method only needs to start a transaction simply, perform data manipulation, then submit, it will be. This is actually a functional specification raised by JDBC3.0, which allows you to roll back to a specified point in a transaction instead of rolling the entire transaction. If the underlying JDBC driver supports the JDBC3.0 specification, the JDO2.0 will use this feature to provide a stronger control to the application code. Transaction Save Points and Nested Transactions are advanced features in transaction processing. Here, the underlying database under the JDO is not necessarily a JDBC database. The object manipulation of the PersistenceManager is defined to manipulate and manage the relationship between the objects of different PersistenCManager managed objects. This is very useful, which may be able to complete the object relationship processing between different data sources, such as an object existing in MySQL contains a reference to an object in an ORACLE, and JDO can automatically complete the reference call between the two. You don't have to make additional operations in the application code, making the application code easier and transparent. Calling the Standard APIJDO2.0 of the enhancer defines an interface method to allow the application to directly call the enhancer to enhance a class code. This can ensure that the application development process is uniform in enhancement, not affected by the manufacturer. In addition, it may be possible to make a standard dynamic enhancer (such as a specific ClassLoader) in some J2EE servers, so that this step is less impact on the development process. Pre-read data API We only need to query an object collection and then trigger the underlying database read operation by accessing its properties, although it is transparent, but sometimes the performance is not very good, such as Reading 1000 objects may cause data transfer of more than 1,000 databases. For example, sometimes we need to access one of the two properties of a set of objects, but JDO may read all attributes and cause a certain performance loss, at this point, slower than JDBC. In some cases, we need to access another group of objects associated with a set of objects, while JDO is delayed by delaying the remaining objects that are referenced. In this case, the data processing time will be extend.
Therefore, we hope that we can give JDO a little prompt before a specific JDO query, let it know how to get the data we need most effectively. JDO2.0 may define some API to let the program tell the JDO to read the data in a query that is immediately taken to enable the application to get the best performance in a specific code segment. BLOB / CLOB Type Support So far, JDO products can select different ways to map Byte [] types into java.sql.blob, or map strings or other data into java.sql.clob, but specific mapping methods Will not normalize, may result in different product operations. Automatic (two-way) object relationship maintenance is that I personally think it is most useful. When we write CMP EJB2.0, we feel very useful between its management's entities, and JDO1.0 is not written in the specification for a variety of considerations, but only in JDO2.0 Re-regulating. This feature is especially useful for many-to-many relationships. For example, we have two classes: teachers and courses, there are more than a corresponding relationship, a teacher can teach multiple courses, and a course can also teach multiple teachers, this relationship is a lot of correspondence. The code is as follows: public class teacher {string name; set teachingcourse;} public class course {string title; set byteachers;} TEACHERS.TEACHINGCOURSES and Course.Byteachers is a two-way multi-relationship, if we To call Someteacher.TeachingCours.Add (someCourse), SomeCourse.byteachers will contain Someteacher, which is guaranteed by JDO, not like JDO1.0 asking users to write code and maintenance. At this point, only JDogenie products offer this feature as a vendor extension. The virtual machine is automatically turned off to automatically close the persistenceManagerFactoryJDO 2.0 will define a method with certain permission protection, allowing the vendor or special user code to call, this method can close a PersistenceManagerFactory involved in the various bottom database resources involved in the reasonably order to prevent resources Terminal occupancy causes system vulnerabilities. In this way, we don't have to consider excessive cleaning operations when writing applications. For example, we write a JDO-based GUI program, we can open a PersistenceManager at the beginning, then simply use it in the program, do not turn off, do not clean up the relevant query results, when the program exits, the underlying JDO The JDBC resources involved will be automatically cleaned, and no resource leakage is caused. In JDBC applications, if you open some ResultSet or Statement resources without shutdown, after the program exits, these resources will never be released. Finally, you will see similar to "Open file handles" Number, no action "error message. Sizeless query When we provide a string that provides a TOLOWERCASE () method, the actual query will not be affected by case, reach some special query purposes. JDO2.0 gives a similar solution. The string conversion in the query will have some type conversion methods such as String (integer) and String (floating point expressions) in the query filter string to improve the flexibility of queries.
Read-only properties Some underlying data sources may have restrictions on data changes, we will be able to write read-only tags on certain classes in the JDO metadata, which can disable changes to this attribute in the JDO layer. If these properties have been changed in the app, they will get an exception. This mechanism will remind the user as soon as possible to change certain properties, more conducive to the error and performance optimization than the data source level. Introduced mode usually, we will have some scope restrictions, such as order status, customer type, etc., these data will only take only values in several limited values, in the non-database Java program, we It can be expressed in the current amount, but once we are applied to the database, we have to do a lot of detection and control to achieve this, and the actual stored value is generally an integer. JDO2.0 will standardize this common function so that we can simply store enumeration values as JDO. For example: We state a predetermined number of orders: public class OrderStatus {private int orderStatus; private OrderStatus (int status) {this.orderStatus = status;} public static OrderStatus NEW = new OrderStatus (1); public static OrderStatus CONFIRMED = new OrderStatus (2); public static orderstatus paid = new orderstatus (3); public static orderstatus delivered = new orderstatus (4); public static orderstatus closed = new OrderStatus (5);} In this way, we can only use ORDER in other classes. .status = ORDERSTATUS.NEW; the statement such as setting the order, and JDO will automatically maintain the corresponding value in the database. Of course, we can also use strings in the database to represent status values, only need to use a string type internal property in the ORDERSTATUS class, and change the constructor to string parameters. Dynamic internal classes support JDO2.0 will support dynamic internal classes, and its main class should also be stored, and there is a multiple-to-one relationship between internal objects and primary objects, so that We can achieve some dependent data types. For example, a customer object has some advanced information, we want to put it in another internal class, you can write: public class customer {string name; public class info {string idcard;}} This, when we use new somecustomer.info ( ) After the JDO saves a related INFO information for the SomeCustomer object. Of course, it can be multiple, and all INFO subclass objects related to a Customer object can be obtained by a specific API. The return value of the query defined in the JDO1.0 specification in the JDO1.0 specification is a collection of instances, but after we have an EJBQL experience, we will miss the EJBSELECTXXX method, you can only choose a certain class. The partial property set of the instance, which saves resources and improves performance. JDO 2.0 will provide a method similar to query.setResult (String Projection), then define a temporary class, which contains the corresponding properties, which is to get the returned property set.
Logwriter supports this feature is basically provided by JDO vendors, letting them have a standard operation log output method, not like each manufacturer to output their own SQL debugging information, eight fairy is over the sea, and the results are the use of different products. Different settings can be made to control the output, trouble of this information. The above is the content that will be defined in the 2.0 specification in JDO1.0. In addition, individuals believe that there are some practical functions to be JDO2.0 needs to be specified, such as dynamic classes, based on SQL92 standard database statistics, and more.
Ok, JDO2.0 is started approaching, let us wait and see, see what surprise will bring us JDO2.0! At the same time, we also pray, jdo2.0 will not be argued like 1.0, three years!
The copyright of this article belongs to the author, but welcome to reprint, the premise is to indicate the source and the original. In addition, welcome to some of my articles in my column, and make valuable comments!
