1、1 英文文献 Object persistence and Java By Arsalan Saljoughy, JavaW, 05/01/97 Object durability, or persistence, is the term you often hear used in conjunction with the issue of storing objects in databases. Persistence is expected to operate with transactional integrity, and as such it is subject to str
2、ict conditions. (See the Resources section of this article for more information on transaction processing.) In contrast, language services offered through standard language libraries and packages are often free from transactional constraints. As well see in this article, evidence suggests that simpl
3、e Java persistence will likely stem from the language itself, while sophisticated database functionality will be offered by database vendors. No object is an island In the real world, you rarely find an object that lacks relations to other objects. Objects are components of object models. The issue
4、of object durability transcends the issue of object model durability and distribution once we make the observation that objects are interconnected by virtue of their relations to one another. The relational approach to data storage tends to aggregate data by type. Rows in a table represent the physi
5、cal aggregate of objects of the same type on disk. The relationships among objects are then represented by keys that are shared across many tables. Although through database organization, relational databases sometimes allow tables that are likely to be used together to be co-located (or clustered)
6、in the same logical partition, such as a database segment, they have no mechanism to store object relationships in the database. Hence, in order to construct an object model, these relationships are constructed from the existing keys at run time in a process referred to as table joins. This is the s
7、ame well-known property of the relational databases called data independence. Nearly all variants of object databases offer some mechanism to enhance the performance of a system that involves complex object relationships over traditional relational databases. To query or to navigate? In storing obje
8、cts on disk, we are faced with the choice of co-locating related objects to better accommodate navigational access, or to store objects in table-like collections that aggregate objects by type to facilitate predicate-based access (queries), or both. The co-location of objects in persistent storage i
9、s an area where relational and object-oriented databases widely differ. The choice of the query language is another area of consideration. Structured Query Language (SQL) and extensions of it have provided relational systems with a predicate-based 2 access mechanism. Object Query Language (OQL) is a
10、n object variant of SQL, standardized by ODMG, but support for this language is currently scant. Polymorphic methods offer unprecedented elegance in constructing a semantic query for a collection of objects. For example, imagine a polymorphic behavior for acccount called isInGoodStanding. It may ret
11、urn the Boolean true for all accounts in good standing, and false otherwise. Now imagine the elegance of querying the collection of accounts, where inGoodStanding is implemented differently based on business rules, for all accounts in good standing. It may look something like: setOfGoodCustomers = s
12、etOfAccounts.query(account.inGoodStanding()； While several of the existing object databases are capable of processing such a query style in C+ and Smalltalk, it is difficult for them to do so for larger (say, 500+ gigabytes) collections and more complex query expressions. Several of the relational d
13、atabase companies, such as Oracle and Informix, will soon offer other, SQL-based syntax to achieve the same result. Persistence and type An object-oriented language aficionado would say persistence and type are orthogonal properties of an object； that is, persistent and transient objects of the same
14、 type can be identical because one property should not influence the other. The alternative view holds that persistence is a behavior supported only by persistable objects and certain behaviors may apply only to persistent objects. The latter approach calls for methods that instruct persistable obje
15、cts to store and retrieve themselves from persistent storage, while the former affords the application a seamless view of the entire object model - often by extending the virtual memory system. Canonicalization and language independence Objects of the same type in a language should be stored in pers
16、istent storage with the same layout, regardless of the order in which their interfaces appear. The processes of transforming an object layout to this common format are collectively known as canonicalization of object representation. In compiled languages with static typing (not Java) objects written
17、 in the same language, but compiled under different systems, should be identically represented in persistent storage. An extension of canonicalization addresses language-independent object representation. If objects can be represented in a language-independent fashion, it will be possible for differ
18、ent representations of the same object to share the same persistent storage. One mechanism to accomplish this task is to introduce an additional level of indirection through an interface definition language (IDL). Object database interfaces can be made through the IDL and the corresponding data stru
19、ctures. The downside of IDL style bindings is two fold: First, the extra level of indirection always requires an additional level of translation, which impacts the overall performance of the system； second, it limits use of database services that are unique to particular vendors and that might be va
20、luable to application developers. 3 A similar mechanism is to support object services through an extension of the SQL. Relational database vendors and smaller object/relational vendors are proponents of this approach； however, how successful these companies will be in shaping the framework for objec
21、t storage remains to be seen. But the question remains: Is object persistence part of the objects behavior or is it an external service offered to objects via separate interfaces? How about collections of objects and methods for querying them? Relational, extended relational, and object/relational a
22、pproaches tend to advocate a separation between language, while object databases - and the Java language itself - see persistence as intrinsic to the language: Native Java persistence via serialization Object serialization is the Java language-specific mechanism for the storage and retrieval of Java
23、 objects and primitives to streams. It is worthy to note that although commercial third-party libraries for serializing C+ objects have been around for some time, C+ has never offered a native mechanism for object serialization. Heres how to use Javas serialization: / Writing foo to a stream (for ex
24、ample, a file) / Step 1. Create an output stream / that is, create bucket to receive the bytes FileOutputStream out = new FileOutputStream(fooFile)； / Step 2. Create ObjectOutputStream / that is, create a hose and put its head in the bucket ObjectOutputStream os = new ObjectOutputStream(out) / Step
25、3. Write a string and an object to the stream / that is, let the stream flow into the bucket os.writeObject(foo)； os.writeObject(new Foo()； / Step 4. Flush the data to its destination os.flush()； The Writeobject method serializes foo and its transitive closure - that is, all objects that can be refe
26、renced from foo within the graph. Within the stream only one copy of the serialized object exists. Other references to the objects are stored as object handles to save space and avoid circular references. The serialized object starts with the class followed by the fields of each class in the inheritance hierarchy. / Reading an object from a stream / Step 1. Create an input stream FileInputStream in = new FileInputStream(fooFile)； / Step 2. Create an object input stream
