Tag: cws_dev300_odbmacros3 User: fs Date: 2008-07-29 07:10:09+0000 Modified: dba/dbaccess/source/core/dataaccess/datasource.cxx
Log: #i76128# File Changes: Directory: /dba/dbaccess/source/core/dataaccess/ ================================================ File [changed]: datasource.cxx Url: http://dba.openoffice.org/source/browse/dba/dbaccess/source/core/dataaccess/datasource.cxx?r1=1.79.4.2&r2=1.79.4.3 Delta lines: +4 -2 ------------------- --- datasource.cxx 2008-07-23 11:44:07+0000 1.79.4.2 +++ datasource.cxx 2008-07-29 07:10:06+0000 1.79.4.3 @@ -7,7 +7,7 @@ * OpenOffice.org - a multi-platform office productivity suite * * $RCSfile: datasource.cxx,v $ - * $Revision: 1.79.4.2 $ + * $Revision: 1.79.4.3 $ * * This file is part of OpenOffice.org. * @@ -1397,6 +1397,7 @@ { try { + // SYNCHRONIZED -> { ModelMethodGuard aGuard( *this ); @@ -1409,6 +1410,7 @@ Reference< css::frame::XStorable> xStorable( xModel, UNO_QUERY_THROW ); xStorable->store(); } + // <- SYNCHRONIZED css::lang::EventObject aFlushedEvent(*this); m_aFlushListeners.notifyEach( &XFlushListener::flushed, aFlushedEvent ); @@ -1429,7 +1431,7 @@ // In general, we have the problem that embedded databases write into their underlying storage, which // logically is one of our sub storage, and practically is a temporary file maintained by the // package implementation. As long as we did not commit this storage and our main storage, - // the changes made by the embedded database engine is not really reflected in the database document + // the changes made by the embedded database engine are not really reflected in the database document // file. This is Bad (TM) for a "real" database application - imagine somebody entering some // data, and then crashing: For a database application, you would expect that the data still is present // when you connect to the database next time. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
