-/*******************************************************************************\r
- * Copyright (c) 2007, 2010 Association for Decentralized Information Management\r
- * in Industry THTH ry.\r
- * All rights reserved. This program and the accompanying materials\r
- * are made available under the terms of the Eclipse Public License v1.0\r
- * which accompanies this distribution, and is available at\r
- * http://www.eclipse.org/legal/epl-v10.html\r
- *\r
- * Contributors:\r
- * VTT Technical Research Centre of Finland - initial API and implementation\r
- *******************************************************************************/\r
-package org.simantics.db.request;\r
-\r
-import org.simantics.db.Session;\r
-import org.simantics.db.WriteGraph;\r
-import org.simantics.db.exception.CancelTransactionException;\r
-import org.simantics.db.exception.DatabaseException;\r
-\r
-/**\r
- * TODO: fix this AGE OLD documentation !! This is totally out of date.\r
- * \r
- * The <code>GraphRequest</code> interface is used to create transaction\r
- * requests to Simantics database implementations. Both read and write\r
- * transaction requests use the same interface.\r
- * \r
- * <p>\r
- * The actual work carried out by the implemented request should be done in the\r
- * <code>perform</code> method. It receives a <code>Graph</code> instance as\r
- * the only argument which is the interface for actually reading and writing the\r
- * graph data model.\r
- * \r
- * <p>\r
- * Transaction requests can be made to the database by creating your own\r
- * <code>GraphRequest</code> instance and putting it in the request queue of\r
- * the database session through the {@link Session} interface. The database\r
- * session is responsible for executing the queued requests in a thread of its\r
- * choice, or possibly/preferably multiple threads. The database session can\r
- * allow multiple read-only requests to occur simultaneously, but read-write\r
- * requests require exclusive database access. In other words only one\r
- * read-write request can be in execution simultaneously.\r
- * \r
- * <p>\r
- * This interface also has two callbacks - <code>handleException</code> for\r
- * allowing handling any exceptions thrown by <code>perform</code> and\r
- * <code>requestCompleted</code> for performing actions after a request has\r
- * been successfully completed.\r
- * \r
- * <p>\r
- * Clients of this interface are encouraged to extend the provided abstract\r
- * implementations or this class or extend their own helper implementations for\r
- * ones particular needs. The provided abstract implementations are:\r
- * <ul>\r
- * <li>{@link WriteRequest} provides default implementations for\r
- * everything except {@link #perform(WriteGraph)}.</li>\r
- * <li>{@link WriteResult} makes it easier for the user to return\r
- * a single result Object from the request.</li>\r
- * </ul>\r
- * \r
- * @author Tuukka Lehtonen\r
- * @see WriteRequest\r
- * @see WriteOnlyRequest\r
- * @see WriteResult\r
- * @see Session\r
- */\r
-public interface Write extends WriteTraits {\r
-\r
- /**\r
- * When a <code>Write</code> request is serviced by the database session the\r
- * method <code>perform</code> is invoked.\r
- * \r
- * <p>\r
- * Perform receives an object instance implementing the\r
- * <code>WriteGraph</code> interface which provides the only way to\r
- * read/write the graph data model. The <code>WriteGraph</code> instance\r
- * must only be valid during the execution of the <code>perform</code>\r
- * method and therefore should not be stored for use outside of its\r
- * execution.\r
- * \r
- * <p>\r
- * The general contract of the method <code>perform</code> is that it may\r
- * take any action whatsoever which involves reading or writing the data\r
- * model through the received WriteGraph instance.\r
- * \r
- * @param g an interface for reading and writing the data model\r
- * @return the result status of the request which affects how the\r
- * transaction proceeds, see GraphRequestStatus for more information\r
- * @throws DatabaseException if anything goes wrong inside the request thread\r
- * @throws CancelTransactionException to indicate that the request needs to\r
- * be cancelled and any changes rolled back\r
- */\r
- void perform(WriteGraph graph) throws DatabaseException;\r
-\r
-}\r
+/*******************************************************************************
+ * Copyright (c) 2007, 2010 Association for Decentralized Information Management
+ * in Industry THTH ry.
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * which accompanies this distribution, and is available at
+ * http://www.eclipse.org/legal/epl-v10.html
+ *
+ * Contributors:
+ * VTT Technical Research Centre of Finland - initial API and implementation
+ *******************************************************************************/
+package org.simantics.db.request;
+
+import org.simantics.db.Session;
+import org.simantics.db.WriteGraph;
+import org.simantics.db.exception.CancelTransactionException;
+import org.simantics.db.exception.DatabaseException;
+
+/**
+ * TODO: fix this AGE OLD documentation !! This is totally out of date.
+ *
+ * The <code>GraphRequest</code> interface is used to create transaction
+ * requests to Simantics database implementations. Both read and write
+ * transaction requests use the same interface.
+ *
+ * <p>
+ * The actual work carried out by the implemented request should be done in the
+ * <code>perform</code> method. It receives a <code>Graph</code> instance as
+ * the only argument which is the interface for actually reading and writing the
+ * graph data model.
+ *
+ * <p>
+ * Transaction requests can be made to the database by creating your own
+ * <code>GraphRequest</code> instance and putting it in the request queue of
+ * the database session through the {@link Session} interface. The database
+ * session is responsible for executing the queued requests in a thread of its
+ * choice, or possibly/preferably multiple threads. The database session can
+ * allow multiple read-only requests to occur simultaneously, but read-write
+ * requests require exclusive database access. In other words only one
+ * read-write request can be in execution simultaneously.
+ *
+ * <p>
+ * This interface also has two callbacks - <code>handleException</code> for
+ * allowing handling any exceptions thrown by <code>perform</code> and
+ * <code>requestCompleted</code> for performing actions after a request has
+ * been successfully completed.
+ *
+ * <p>
+ * Clients of this interface are encouraged to extend the provided abstract
+ * implementations or this class or extend their own helper implementations for
+ * ones particular needs. The provided abstract implementations are:
+ * <ul>
+ * <li>{@link WriteRequest} provides default implementations for
+ * everything except {@link #perform(WriteGraph)}.</li>
+ * <li>{@link WriteResult} makes it easier for the user to return
+ * a single result Object from the request.</li>
+ * </ul>
+ *
+ * @author Tuukka Lehtonen
+ * @see WriteRequest
+ * @see WriteOnlyRequest
+ * @see WriteResult
+ * @see Session
+ */
+@FunctionalInterface
+public interface Write extends WriteTraits {
+
+ /**
+ * When a <code>Write</code> request is serviced by the database session the
+ * method <code>perform</code> is invoked.
+ *
+ * <p>
+ * Perform receives an object instance implementing the
+ * <code>WriteGraph</code> interface which provides the only way to
+ * read/write the graph data model. The <code>WriteGraph</code> instance
+ * must only be valid during the execution of the <code>perform</code>
+ * method and therefore should not be stored for use outside of its
+ * execution.
+ *
+ * <p>
+ * The general contract of the method <code>perform</code> is that it may
+ * take any action whatsoever which involves reading or writing the data
+ * model through the received WriteGraph instance.
+ *
+ * @param g an interface for reading and writing the data model
+ * @return the result status of the request which affects how the
+ * transaction proceeds, see GraphRequestStatus for more information
+ * @throws DatabaseException if anything goes wrong inside the request thread
+ * @throws CancelTransactionException to indicate that the request needs to
+ * be cancelled and any changes rolled back
+ */
+ void perform(WriteGraph graph) throws DatabaseException;
+
+}
Code Review / simantics / platform.git / blobdiff