He jdo2.0 plans to start
Recently, Xin Wen Sun officially joined jdocentral.com as one of its charter member, indicating Sun's formal support and promotion for JDO. In the past, Sun proposed the JDO specification, but it was always not enough in terms of formal support. It seems that it has always provided limited publicity because it has an impact on its EJB system, jdocentral.com is the main promotion site of JDO. But now, the JDO specification has been proposed for nearly a year and a half, and many outstanding products have emerged one after another. It seems that there will be a new tornado, and sun will see that the time is ripe, at this time, it will not jump out, but it will be more time! We were delighted to see that Sun officially joined jdocentral and started preparations for the jdo2.0 plan.
Information Source: http://www.theserverside.com/home/thread.jsp? Thread_id = 20875 & article_count = 37
We have mentioned that jdo1.0 has been proposed for a year and a half, but it seems that the public is not accepting enough, and not many application development companies are enthusiastic enough. In addition to Sun's lack of pushing, this is also related to jdo1.0's limitations. We expect jdo1.0 to be able to solve the development of most small and medium-sized database applications, that is, it can basically replace JDBC, but does not support ing and database statistics functions is the biggest defect of jdo1.0. I have always hoped that jdo2.0 can solve these problems. At least a set of optional APIs can be provided for JDBC, which does not affect JDO in other types of databases (such as files, XML, and OODB). In general, jdo1.0 can meet most of our database application development needs, but adding these features will be more convenient.
Let's take a look at what jdo2.0 will bring to us. In fact, the jdo1.0 specification has already put forward some functions that are already of interest to most people in the last chapter. However, due to immature ideas or inconsistent opinions, further verification is pending, so we have to put it in jdo2.0 and then normalize it. Therefore, we have reason to believe that jdo2.0 will first include such content, at least most of which will be included. Here, I will briefly explain the topics pushed to the next version of the jdo1.0 specification:
- Nested transactions
Transaction support is a required function of a Database. However, in actual development, we often need multi-level transactions. Failure of an intermediate operation will not cause the rollback of the entire transaction, instead, roll back a small number of operations and then perform other operations. Jdo2.0 will normalize this feature. Of course, it may be an optional feature that allows the vendor to choose whether to implement it, but once implemented, you can use standard APIs to execute nested transactions.
For example, when writing business logic, there may be many logical methods. Each method needs to update the data object, that is, a transaction needs to be used in the method. If one method may be called by another method, a "transaction has started" exception may occur in jdo1.0. Therefore, we have to use the following code to compile every logical method, to ensure that the mutual calls between them will not go wrong:
Public void logicaloperation1 (){
Transaction Tx = PM. currenttransaction ();
Boolean newtx =! TX. isactive ();
If (newtx) Tx. Begin ();
// Update data objects here
If (newtx) Tx. Commit ();
}
In jdo2.0, we don't have to worry about this problem. Every method simply needs to start a transaction, perform data operations, and then commit.
- Transaction retention point
This is actually a functional specification proposed by jdbc3.0. It allows you to roll back to a specified point in a transaction, rather than rolling back the entire transaction. If the underlying JDBC driver supports the jdbc3.0 specification, jdo2.0 will use this feature to provide stronger control over application code. Both transaction retention points and nested transactions are advanced functions in transaction processing. Here, the underlying database under JDO is not necessarily a JDBC database.
- Cross-persistencemanager object manipulation
Define standard interfaces to manipulate and manage the relationships between objects managed by different persistencmanagers. This is very useful and may be able to process the object relationship between different data sources. For example, an object in MySQL contains a reference pointing to an object in Oracle, JDO can automatically complete the reference call between the two, without additional operations in the application code, so that the application code is simpler and more transparent.
- Call the standard API of the booster
Jdo2.0 defines an interface method for the application to directly call the enhancement tool to enhance the class code of a class. This ensures that the uniformity of the application development process is not affected by the vendor. In addition, you may be able to use this feature to make a standard dynamic booster (such as a specific classloader) in some J2EE servers, so that the enhancement step has less impact on the development process.
- Pre-read data API
When writing application code, we only need to query an object set and then access its attributes to trigger the underlying database read operations. Although transparent, but sometimes the performance is not very good. For example, reading 1000 objects may cause more than 1000 database data transfers. For another example, sometimes we need to access one or two attributes of a group of objects, but JDO may read all the attributes and cause some performance loss. In this regard, it is slower than JDBC. In other cases, we need to access another set of objects related to a group of objects at the same time, and JDO is by default to call other referenced objects in a delayed manner, in this case, the data processing time will be extended. Therefore, we hope that we can give JDO a prompt before a specific JDO query to let it know how to get the data we need most effectively.
Jdo2.0 may define some APIs to allow the program to tell JDO what strategy to adopt to read data in a query immediately, so that the application can obtain the best performance in a specific code segment.
- Blob/clob Type Support
So far, the JDO product can map the byte [] type to Java in different ways. SQL. blob, or map the string or other data to Java. SQL. clob, but the specific ing method is not normalized, may lead to different products running the same application performance differences.
- Automatic (bidirectional) object relationship maintenance
This is what I personally think is most useful. When writing CMP's ejb2.0, we will feel that the two-way relationship between entities managed by CMP is very useful, and jdo1.0 has not written this point into the specification for various considerations, in jdo2.0. This function is especially useful for many-to-many relationships. For example, we have two categories: teachers and courses. They have a lot of corresponding relationships. One teacher can teach multiple courses, and one course can also be taught by multiple teachers, this relationship is a lot of mappings. The Code is as follows:
Public class teacher {
String name;
Set teachingcourses;
}Public class course {
String title;
Set byteachers;
}
In the two classes, teachers. teachingcourses and course. byteachers is a bidirectional many-to-many relationship. If we call someteacher. teachingcourses. add (somecourse), then somecourse. byteachers will include someteacher, which is ensured by JDO. Unlike jdo1.0, users are required to write and maintain their own code.
Currently, only the jdogenie product provides this feature as a vendor extension.
- Persistencemanagerfactory is automatically disabled when the VM exits.
Jdo2.0 defines a method with certain permissions to allow the vendor or special user code to be called. This method can close the underlying database resources involved in a persistencemanagerfactory in a reasonable order, to prevent system vulnerabilities caused by persistent resource occupation. In this way, when writing an application, we do not have to consider too many cleanup operations.
For example, if we write a JDO-based GUI program, we can open a persistencemanager at the beginning, and then simply use it in the program without closing or clearing the relevant query results, when the program exits, the underlying JDO can automatically clean up the involved JDBC resources without causing resource leakage. In a JDBC application, if you use JDBC to open some resultset or statement resources but not close them, these resources will never be released after the program exits, when you access the database again, you will see an error message similar to "The opened file handle exceeds the maximum number of systems and cannot perform operations.
- Case Insensitive Query
When we provide a tolowercase () method for a string, the actual query will not be affected by the case, to achieve some special query purposes. Jdo2.0 will provide a similar solution.
- String Conversion in the query
There will be some type conversion methods such as string (integer value) and string (floating-point expression) in the query filter string to improve the flexibility of the query.
- Read-only attribute
Some underlying data sources may have restrictions on data changes. we can write a read-only mark on some attributes of some classes in the JDO metadata so that changes to this attribute can be prohibited at the JDO layer, if these attributes are modified in the application, an exception is returned. This mechanism will remind users as early as possible not to change certain attributes, which is more conducive to troubleshooting and performance optimization than data source-Level Error prompts.
- Enumeration Mode
Generally, some data has certain limits, such as the order status and customer type. These data only takes a few limited values, in non-database Java programs, we can use class constants for representation, but once applied to the database, we have to do a lot of detection and control to achieve this goal, the actually stored value is generally an integer.
Jdo2.0 standardizes this common feature so that we can simply store enumerated values like JDO. For example, we specify several States for an order:
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 statements such as order. Status = orderstatus. New; in other classes to set the order status, and JDO will automatically maintain the corresponding values in the database. Of course, we can also use strings in the database to represent the State value. We only need to use a string-type internal attribute in the orderstatus class and change the constructor to a string parameter.
- Support for dynamic internal classes
Jdo2.0 will support dynamic internal classes, and its main classes should also be stored, and there will be an automatically implemented many-to-one relationship between the internal class object and the main object. In this way, we can implement some dependent data types. For example, if a customer object has some advanced information and we want to put it in another internal class, we can write it like this:
Public Class Customer {
String name;
Public class info {
String idcard;
}
}
In this way, when we use new somecustomer. Info ();, JDO will save a related info information for the somecustomer object. Of course, there can also be multiple info subclass objects related to a customer object through a specific API.
- Query partial attributes
The query return values defined in the jdo1.0 specification are a collection of instances of a certain class. However, after learning about ejbql, we will miss the ejbselectxxx method, you can select only some attribute sets of an instance of a class to save resources and improve performance. Jdo2.0 will provide a method similar to query. setresult (string projection), and then define a temporary class, which contains the corresponding attributes to get the returned attribute set.
- Logwriter support
This function is basically provided for JDO vendors and allows them to have a standard operation log output method. Unlike the current situation where different vendors output their own SQL debugging information, the result is that users must set different products to control the output of the information, which is troublesome.
The above is what will be defined in the 2.0 specification as mentioned in jdo1.0. In addition, I personally think that some practical functions also need to be specified by jdo2.0, such as dynamic class enhancement and sql92-based database statistics.
Now, jdo2.0 is coming soon. Let's wait and see what surprises jdo2.0 will bring to us! At the same time, we also pray that jdo2.0 will not be as controversial as jdo2.0 for three years!
The copyright in this article belongs to the author, but you are welcome to repost it on the premise that the source and original author are indicated. In additionMy columnView my other articles and provide valuable comments!
