Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

More Java Pitfalls Share Reactor - Daconta M,C.

Daconta M,C. More Java Pitfalls Share Reactor - Wiley publishing, 2003. - 476 p.
ISBN: 0-471-23751-5
Download (direct link): morejavapitfallssharereactor2003.pdf
Previous << 1 .. 135 136 137 138 139 140 < 141 > 142 143 144 145 146 147 .. 166 >> Next

190 outputStream2.writeObject(getFirstname());
191 outputStream2.writeObject(getLastname());
192 outputStream2.writeObject(getSsn());
193 outputStream2.writeObject(getComments());
194
195 // close stream
196 outputStream2.flush();
197 outputStream2.close();
198
199 }
200 catch(IOException ioe) {
201 System.err.println("IOERROR: " + ioe);
202 }
203 catch(Exception e) {
204 System.err.println("ERROR: " + e);
205 }
206 */
207
208 logger.info("[serializeBean:write] writing data.");
209 }
Listing 46.1 (continued)
If you've used Remote Method Invocation in your software implementations, you've come across serialization. With RMI implementations, objects are compressed into byte streams when they are marshaled across a network. Performance becomes an issue during the deserialization of objects because it involves the conversion of byte array elements into object and data types. This process involves the use of reflection to discover properties of an object.
Some shortcomings with serialization are that once an object is written to, additional writes are ignored because the object reference is maintained, unless the reset() method is invoked. Certainly, performance issues have always been associated with serialization because of disk read (reflection)/write operations, but depending on your situation, serialization can be a perfectly appropriate persistence solution in your enterprise deployments. However, if your application requires concurrency in database access and queries, then Java Data Objects can be a solution for you.
JDO and Data Persistence 391
-3 JDO Test Microsoft Internet Explorer provided by -
File * Edit View Favorites Tools Help
41 ^Search ^Fa/ortes .jHistoi | ^
Co gk| gf SeachSv'eO
A
JDO Test
Product Name:
Product Price:
Product Count: 1
Add |
Product Price ($) # m Stock Delete item?
I $1000.0 to00 Delete?
21 S 13.98 2000 Delete?
13 $99.0 10 00 Delete?
Delete |

a?] Done Ql Local Intranet
*Start| 300(3 ** | _^pics 11^1 JDO lest Mic... W]Documem2 - Mic | |^l js,$ 0 54 PM
Figure 46.1 JDO Test form.
Now that you have a better understanding of serialization, I think you'll have a better appreciation of JDO and the great promise it offers in abstracting away the inane details of the SQL language implementation in Java applications.
A simple inventory program, shown in Listing 46.2, was crafted with a recent open-source JDO offering from the Apache Software Foundation (ASF) called Objec-tRelational Bridge (OJB). OJB is a fairly ambitious project by the good folks at the ASF, and although their JDO implementation is not fully compliant with the JDO Draft (JSR-012), ASF promises to move in that direction. OJB uses a PersistentBroker API as its persistence kernel and has its JDO implementation built on top of it and XML data mappings that bind to your database elements.
What makes OJB JDO worthy of examination is its ability for transparent persistence of database elements in the form of Java objects. JDO abstracts away the complexities of SQL transactions and allows developers to query instances of data stores with very fine granularity and without having to understand the intimate details about the database structure itself.
With OJB JDO, caches can be transactional, which means that each cache area can maintain a different transactional view of the data store instances. This is an important concept that separates it from the serialization process described above.
Mentioned earlier, the following code is a simple inventory Web application that inserts, deletes, and displays inventory items using the OJB JDO libraries. The jdoForm is a simple JavaServer Page that accepts user requests and interfaces with a back-end MySQL database.
392 Item 46
001
002 <%@page import="org.apache.ojb.tutorial4.*" %>
003 <%@page import="org.apache.ojb.jdo.PersistenceManagerImpl" %>
004 <%@page import=
005 "org.apache.ojb.jdo.PersistenceManagerFactorylmpl" %>
006 <%@page import="javax.jdo.PersistenceManager" %>
007 <%@page import="javax.jdo.Transaction" %>
008
009 <%@page import="org.odmg.*" %>
010
011 <%@page import="javax.jdo.Query" %>
012 <%@page import="java.util.Collection" %>
013
014 <%@page import="javax.jdo.PersistenceManager" %>
015 <%@page import="javax.jdo.PersistenceManagerFactory" %>
016 <%@page import="java.io.BufferedReader" %>
017 <%@page import="java.io.InputStreamReader" %>
018 <%@page import="java.util.Vector" %>
019 <jsp:useBean id="pm"
020 class="org.javapitfalls.item46.jdoPersistenceMgr"
021 scope="application"/>
022 <jsp:useBean id="validate"
023 class="org.javapitfalls.item46.jdoBean" scope="request">
024 <jsp:setProperty name="validate" property="*"/>
025 </jsp:useBean>
026 <head>
027 <title>JDO Test</title>
028 </head>
029
030 <%
031 String addItem=request.getParameter("Add");
032 String deleteItem=request.getParameter("Delete");
033
034 if (addItem != null)
Previous << 1 .. 135 136 137 138 139 140 < 141 > 142 143 144 145 146 147 .. 166 >> Next