objectbridge-developers Mailing List for ObJectRelationalBridge (Page 40)
Brought to you by:
thma
Menu
▾
▴
objectbridge-developers — public list for developer issues
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(33) |
Feb
(8) |
Mar
(3) |
Apr
(1) |
May
(18) |
Jun
(6) |
Jul
(15) |
Aug
(71) |
Sep
(29) |
Oct
(43) |
Nov
(77) |
Dec
(54) |
| 2002 |
Jan
(54) |
Feb
(147) |
Mar
(144) |
Apr
(163) |
May
(307) |
Jun
(240) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <ri...@ya...> - 2002-02-06 08:09:46
|
Thomas,
Thanks, it worked!!!
In single VM mode I get this message:
[BOOT] INFO: OJB.properties: =
file:/C:/Java/Tomcat401/webapps/charlie-dev/WEB-INF
/classes/OJB.properties
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
But It works. I can make two threads read data from the same table =
concurrently.
When I tried to run OJB in C/S mode, I got this exception:
[ODMG] ERROR: null
org.odmg.TransactionNotInProgressException
at =
ojb.broker.server.PersistenceBrokerClient.commitTransaction(Persisten
ceBrokerClient.java:192)
at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:230)
at =
charlie.ojb.ProyectoManagerOJB.getEmpleado(ProyectoManagerOJB.java:39
0)
at charlie.web.LogonAction.perform(LogonAction.java:49)
at =
org.apache.struts.action.ActionServlet.processActionPerform(ActionSer
vlet.java:1786)
<snip>
And in the C/S Console:
------------------------------
C:\charlie>java -cp =
c:\Charlie\build\WEB-INF\classes;lib/mm.mysql-2.0.8-bin.jar;
lib/jta-spec1_0_1.jar;lib/xerces-J_1.4.0.jar;lib/ojb-0.7.327.jar =
ojb.broker.serv
er.PersistenceBrokerServer repository.xml
[BOOT] WARN: no port specified, will use default: 2001
[BOOT] INFO: OJB.properties: =
file:/C:/charlie/build/WEB-INF/classes/OJB.properti
es
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[ojb.broker.metadata.RepositoryXmlHandler] WARN: unknown =
isolation-level: read-u
ncomitted using RW_UNCOMMITTED as default
[BOOT] INFO: PersistenceBrokerServer is accepting connections on port =
2001
[ojb.broker.server.RequestProcessor] ERROR: =
ojb.broker.server.Request@7725c4
[ojb.broker.server.RequestProcessor] ERROR: null
I suppose I would not need to use the Client/Server mode anymore, since =
now OJB is working in single JVM mode, concurrently... I do not need the =
load balancing stuff yet... What do you think?
I'll try to get some sleep (it's 3am here, I downloaded your patch =
almost inmediatly), and tomorrow I'll finish testing with more cases of =
concurrency of web clients.
THANKS for your great work!
Greetings,
Ricardo Arguello
----- Original Message -----=20
From: "Thomas Mahler" <tho...@ho...>
To: "Ricardo Arg=FCello" <ri...@ya...>
Cc: <obj...@li...>
Sent: Wednesday, February 06, 2002 1:20 AM
Subject: Re: [OJB-developers] Concurrent access not posible with 0.7.325 =
in C/S mode
> Hi Ricardo,
>=20
> I just placed a new release (0.7.327) on the OJB download page.
> I modified the PersistenceBrokerFactory and the ODMG implementation.
> Now in singlevm mode each transaction will obtain its own broker =
instance.
> During comit() or abort() the broker instances are released to a pool.
>=20
> I hope this will solve at least some of your problems.
>=20
> This is no release build. thus there are no TestCases yet that check =
the=20
> implemented features. There may be bugs!
>=20
> HTH,
>=20
> Thomas
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
|
|
From: Thomas M. <tho...@ho...> - 2002-02-06 06:21:02
|
Hi Ricardo, I just placed a new release (0.7.327) on the OJB download page. I modified the PersistenceBrokerFactory and the ODMG implementation. Now in singlevm mode each transaction will obtain its own broker instance. During comit() or abort() the broker instances are released to a pool. I hope this will solve at least some of your problems. This is no release build. thus there are no TestCases yet that check the implemented features. There may be bugs! HTH, Thomas |
|
From: Mahler T. <tho...@it...> - 2002-02-05 07:41:34
|
Hi Jakob,
> -----Urspr=FCngliche Nachricht-----
> Von: Jakob Braeuchi [mailto:jbr...@ho...]
> Gesendet: Montag, 4. Februar 2002 20:32
> An: obj...@li...
> Betreff: [OJB-developers] ojb 7.325 QueryBySQL / SqlBasedRsIterator
>=20
>=20
> hi,
>=20
> when querying the db using queryBySql the sequence of the=20
> returned columns
> is determined by the query not the columnNumber in the repository.
>=20
> sql =3D "select * from tabPerson where name like '%er'";
> query =3D new QueryBySQL(Person.class, sql);
>=20
> this can cause problems in JdbcAccess::GetObjectFromColumn. i=20
> suggest to use
> the resultset to find the columnNumber by the columnName:
>=20
> static Object getObjectFromColumn(ResultSet rs,=20
> FieldDescriptor fld) throws
> SQLException
> {
> int jdbcType =3D getJdbcType(fld);
> // int columnId =3D fld.getColNo();
> int columnId =3D rs.findColumn(fld.getColumnName()); =20
> //use columnId
> from rs BRJ
> return getObjectFromColumn(rs, jdbcType, columnId);
> }
>=20
> i have a question regarding=20
> SqlBasedRsIterator::getObjectFromResultSet()
>=20
> protected Object getObjectFromResultSet() throws=20
> PersistenceBrokerException
> {
> // provide m_row with data of current row
> m_mif.getRowReader().readObjectArrayFrom(m_rs, m_mif, m_row);
> // assert: m_row is filled from db
>=20
> ...
>=20
> why do we need the call to readObjectArrayFrom() when super=20
> is called later
> on, which will call readObjectArrayFrom() again ?
>=20
I did not check the code. But if really works as you say it is =
definitely a
bug. readObjectArrayFrom() must only be called once for each ResultSet =
row!
-- Thomas
> jakob
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
|
|
From: Daniel Fernn. E. <dfe...@wn...> - 2002-02-04 19:36:23
|
Hi ---------- Original Message ---------------------------------- From: Mahler Thomas <tho...@it...> Date: Mon, 4 Feb 2002 08:57:18 +0100 >Hi Doug, Hi Daniel, > >> -----Urspr=FCngliche Nachricht----- >> Von: Doug Currie [mailto:de...@fl...] >> Gesendet: Samstag, 2. Februar 2002 23:54 >> An: ojb >> Cc: dn...@us... >> Betreff: [OJB-developers] concurrent broker transactions in single vm >> mode >> >> >> A broker pool is required to implement odmg concurrent transactions >> effectively. > >I agree ! > >> Daniel Fernandez, you have been looking at a broker pool >> implementation; have you also thought about how to use this pool at >> the odmg level in single vm mode? >> > >I don't know what exactly Daniel did, but I suggested to use the >PersistenceBrokerFactory to use a pool to reach fresh PersistenceBrokerImp= l >instances to each ODMG transaction. I'm using PersistenceBrokerFactory as you say, i haven't got a chance to lo= ok at ODMG impl >On transaction commit and abort the PB instance should be returned to the >pool. I'm trying to do it, but still have some issues >> Having looked at this a bit, it seems to me that one broker per odmg >> transaction is a logical way to proceed. > >agreed. agreed too >> Many places that get a broker from OJB either >> can just as easily get it from the transaction, or don't care what >> broker they end up with since they are just using it for access to the >> cache or metadata. > >agreed. In my code you get a broker from brokerfactory then the broker get a connec= tion from the transactionManager(i'm using JTA) when transaction begins bye |
|
From: Jakob B. <jbr...@ho...> - 2002-02-04 19:31:35
|
hi,
when querying the db using queryBySql the sequence of the returned columns
is determined by the query not the columnNumber in the repository.
sql = "select * from tabPerson where name like '%er'";
query = new QueryBySQL(Person.class, sql);
this can cause problems in JdbcAccess::GetObjectFromColumn. i suggest to use
the resultset to find the columnNumber by the columnName:
static Object getObjectFromColumn(ResultSet rs, FieldDescriptor fld) throws
SQLException
{
int jdbcType = getJdbcType(fld);
// int columnId = fld.getColNo();
int columnId = rs.findColumn(fld.getColumnName()); //use columnId
from rs BRJ
return getObjectFromColumn(rs, jdbcType, columnId);
}
i have a question regarding SqlBasedRsIterator::getObjectFromResultSet()
protected Object getObjectFromResultSet() throws PersistenceBrokerException
{
// provide m_row with data of current row
m_mif.getRowReader().readObjectArrayFrom(m_rs, m_mif, m_row);
// assert: m_row is filled from db
...
why do we need the call to readObjectArrayFrom() when super is called later
on, which will call readObjectArrayFrom() again ?
jakob
|
|
From: Doug C. <de...@fl...> - 2002-02-04 08:32:28
|
> ([OT] why an 'e' not a 'D' ?) I use my "final" instead of my "initial." It's what I've been called for at least 25 years. My fraternity brothers made it stick. e |
|
From: Doug C. <de...@fl...> - 2002-02-04 08:27:41
|
>> In two tests I used: <MappingRepository isolation="repeatable-read">
> Hmm, is this a typo? isolation must be declared per ClassDescriptor?
I thought this construction changed the default isolation for all
classes. I overlooked the fact that Article's isolation
level is set explicitly. (I was looking at test.ojb.broker.Article
instead of test.ojb.odmg.Article).
So, I ran the tests with the <MappingRepository isolation="repeatable-read">
but otherwise unmodifed repository using LockStrategyFactory.getStrategyFor()
to see the isolation level...
run_odmg_example:
[junit] .[BOOT] INFO: OJB.properties: file:/D:/ejava/ojb-0.7.315/build/test/ojb/OJB.properties
[junit] ....[ODMG] ERROR: !!! L: ojb.odmg.locking.RepeatableReadStrategy@406199
[junit] [ODMG] ERROR: !!! L: not read locked!
[junit] .[ODMG] ERROR: !!! L: ojb.odmg.locking.ReadUncommittedStrategy@61f24
[junit] [ODMG] ERROR: !!! not read locked !!!
[junit] [ODMG] ERROR: !!! dirty cache !!!
the RepeatableReadStrategy object is the result of a query on a named
DList (remember my ealier bug report). You are right, the Article is
ReadUncommittedStrategy. So I changed the Article class isolation...
run_odmg_example:
[junit] .[BOOT] INFO: OJB.properties: file:/D:/ejava/ojb-0.7.315/build/test/ojb/OJB.properties
[junit] ....[ODMG] ERROR: !!! L: ojb.odmg.locking.RepeatableReadStrategy@406199
[junit] [ODMG] ERROR: !!! L: not read locked!
[junit] .[ODMG] ERROR: !!! L: ojb.odmg.locking.RepeatableReadStrategy@406199
[junit] [ODMG] ERROR: !!! dirty cache !!!
and now we do have a read lock after the query, but still have the
implicit write lock "bug." Er, feature.
<snip>
> As a consequence of our discussion I placed a note on the feature list and
> on the roadmap page stating that implicit locking is not fully implemented
> and that users must use explicit lock to have proper tx isolation.
Very good. That's all we really need.
> I assume we really need object clones per ODMG transaction to have a clean
> optimistic locking.
> Apropos: Jakob implemented locking and it is already integrated into the
> latest 0.7.325 release!
I meant to write about this. It looks very nice. It is everything we'd
need at the broker level for optimistic locking, but as you say, unless
we have multiple clones of objects (in the simplest case one per
transaction) it won't provide transaction isolation.
e
|
|
From: <ri...@ya...> - 2002-02-04 07:59:19
|
More info:
I'm using "read-uncommited" in every class mapping and READ-locking in =
OJB.properties.
----- Original Message -----=20
From: "Ricardo Arg=FCello" <ri...@ya...>
To: "Thomas Mahler" <tho...@ho...>; =
<obj...@li...>
Sent: Monday, February 04, 2002 2:45 AM
Subject: [OJB-developers] Concurrent access not posible with 0.7.325 in =
C/S mode
Thomas,
I have just downloaded the new 0.7.325 distribution, and I hoped it =
would make C/S mode work...
But it doesn't, I'm still getting Exceptions when two threads try to =
access the repository (read) at the same time.
This is the new stack trace:
-------------------------------------------------------------------------=
-----
[ODMG] ERROR: Caught EOFException while reading the stream header
Caught EOFException while reading the stream header
at =
ojb.broker.server.PersistenceBrokerClient.callServer(PersistenceBroke
rClient.java:115)
at =
ojb.broker.server.PersistenceBrokerClient.callServer(PersistenceBroke
rClient.java:55)
at =
ojb.broker.server.PersistenceBrokerClient.beginTransaction(Persistenc
eBrokerClient.java:160)
at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:225)
at =
charlie.ojb.ProyectoManagerOJB.getEmpleado(ProyectoManagerOJB.java:39
0)
at charlie.web.LogonAction.perform(LogonAction.java:49)
at =
org.apache.struts.action.ActionServlet.processActionPerform(ActionSer
vlet.java:1786)
at =
org.apache.struts.action.ActionServlet.process(ActionServlet.java:158
5)
at =
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at =
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at =
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:201)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2344)
at =
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:164)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
462)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:163)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1011)
at =
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1106)
at java.lang.Thread.run(Unknown Source)
-------------------------------------------------------------------------=
-----
***
I usually get this stack trace the first time I try to access =
concurrently.
From then on, I get this stack trace:
-------------------------------------------------------------------------=
-----
[ODMG] ERROR: null
org.odmg.TransactionInProgressException
<<no stack trace available>>
org.odmg.QueryException
at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:250)
at =
charlie.ojb.ProyectoManagerOJB.getEmpleado(ProyectoManagerOJB.java:39
0)
at charlie.web.LogonAction.perform(LogonAction.java:49)
at =
org.apache.struts.action.ActionServlet.processActionPerform(ActionSer
vlet.java:1786)
at =
org.apache.struts.action.ActionServlet.process(ActionServlet.java:158
5)
at =
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at =
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at =
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:201)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2344)
at =
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:164)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
462)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:163)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1011)
at =
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1106)
at java.lang.Thread.run(Unknown Source)
-------------------------------------------------------------------------=
-----
Please help me make OJB work in a multithreading scenario (website: =
Struts + JDO). I need to deploy these week, but if I can't make the =
persistance layer work in a multithreading scenario, I'll have to code =
everything in JDBC again... and you know, that's incredibly fun!
Thanks in advance
Ricardo Arguello
_______________________________________________
Objectbridge-developers mailing list
Obj...@li...
https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
|
|
From: Mahler T. <tho...@it...> - 2002-02-04 07:58:00
|
Hi Doug, Hi Daniel,
> -----Urspr=FCngliche Nachricht-----
> Von: Doug Currie [mailto:de...@fl...]
> Gesendet: Samstag, 2. Februar 2002 23:54
> An: ojb
> Cc: dn...@us...
> Betreff: [OJB-developers] concurrent broker transactions in single vm
> mode
>=20
>=20
> A broker pool is required to implement odmg concurrent transactions
> effectively.=20
I agree !
> Daniel Fernandez, you have been looking at a broker pool
> implementation; have you also thought about how to use this pool at
> the odmg level in single vm mode?
>=20
I don't know what exactly Daniel did, but I suggested to use the
PersistenceBrokerFactory to use a pool to reach fresh =
PersistenceBrokerImpl
instances to each ODMG transaction.
On transaction commit and abort the PB instance should be returned to =
the
pool.=20
> Having looked at this a bit, it seems to me that one broker per odmg
> transaction is a logical way to proceed.=20
agreed.
> Most code that needs to
> reference a broker is also grabbing a reference to a transaction.
> Unfortunately a 1-1 relationship between DatabaseImpl and broker in
> the current code is assumed by OJB.getBroker, but this can be fixed
> pretty easily I think.=20
IMHO this is a separate issue and needs some more thinking.
> Many places that get a broker from OJB either
> can just as easily get it from the transaction, or don't care what
> broker they end up with since they are just using it for access to =
the
> cache or metadata.
agreed.
>=20
> For example, sequences such as (e.g., OQLQueryImpl.execute):
>=20
> // retrieve a broker instance
> PersistenceBroker broker =3D =
OJB.getInstance().getBroker();
>=20
> //obtain current ODMG transaction
> Transaction tx =3D =
OJB.getInstance().currentTransaction();
>=20
> // we allow queries even if no ODMG transaction=20
> is running.
> // thus we have to provide a pseudo tx if necessary
> boolean needsCommit =3D false;
> if (tx =3D=3D null)
> {
> tx =3D OJB.getInstance().newTransaction();
> }
>=20
> // we allow to work with unopened transactions.
> // we assume that such a tx is to be closed after=20
> performing the query
> if (!tx.isOpen())
> {
> tx.begin();
> needsCommit =3D true;
> }
>=20
> would get the trasaction first and become
>=20
> //obtain current ODMG transaction
> Transaction tx =3D =
OJB.getInstance().currentTransaction();
>=20
> // we allow queries even if no ODMG transaction=20
> is running.
> // thus we have to provide a pseudo tx if necessary
> boolean needsCommit =3D false;
> if (tx =3D=3D null)
> {
> tx =3D OJB.getInstance().newTransaction();
> }
>=20
> // we allow to work with unopened transactions.
> // we assume that such a tx is to be closed after=20
> performing the query
> if (!tx.isOpen())
> {
> tx.begin();
> needsCommit =3D true;
> }
> // retrieve the transactions's broker instance
> PersistenceBroker broker =3D tx.getBroker(); // THE =
CHANGE
>=20
>=20
Yes, we will have to change all references to =
OJB.getInstance().getBroker()
to=20
OJB.getInstance().currentTransaction().getBroker()
I will change all the ODMG code to consistently do this!=20
> If you need a hand with this let me know. I am interested in seeing
> the omdg layer improved with more concurrency for single vm
> applications.
>=20
Thanks for in depth analysis! We really have to get rid of these
bottlenecks.
Thomas
> e=20
([OT] why an 'e' not a 'D' ?)
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20
|
|
From: Mahler T. <tho...@it...> - 2002-02-04 07:46:30
|
Hi Doug, > -----Urspr=FCngliche Nachricht----- > Von: Doug Currie [mailto:de...@fl...] > Gesendet: Samstag, 2. Februar 2002 18:52 > An: Thomas Mahler > Cc: ojb > Betreff: Re[2]: [OJB-developers] Re: OJB-ODMG does[n't]=20 > support implicit > locking >=20 >=20 > Hello Thomas, >=20 > Saturday, February 02, 2002, 6:35:51 AM, you wrote: > <snip> > TM> Hmm. If you are NOT using "read-uncommited" and there is no > TM> READ-lock in the LockMap it must be a bug! Which isolation level > TM> are you using for class Article ? >=20 > In two tests I used: <MappingRepository = isolation=3D"repeatable-read"> Hmm, is this a typo? isolation must be declared per ClassDescriptor? > as well as the usual repository.xml; both gave the same results. So > yes, I think there's a bug. >=20 > TM> Maybe we need different semantics for the isolation=20 > levels? Did you have=20 > TM> a look at my doc concerning the LockManager? It contains a table=20 > TM> demonstrating the behaviour of all isolation levels=20 > currently implemented. >=20 > I will look at it more closely. I've hestitated to use the default > read-uncommited isolation level because I don't understand the > implications of the semantics. It's one thing to have transactions > overlap; it's quite another to read a partially modified object. I am > not that brave! >=20 As a consequence of our discussion I placed a note on the feature list = and on the roadmap page stating that implicit locking is not fully = implemented and that users must use explicit lock to have proper tx isolation. I assume we really need object clones per ODMG transaction to have a = clean optimistic locking. Apropos: Jakob implemented locking and it is already integrated into = the latest 0.7.325 release! Thomas > Regards, >=20 > e >=20 >=20 > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >=20 |
|
From: <ri...@ya...> - 2002-02-04 07:45:34
|
Thomas,
I have just downloaded the new 0.7.325 distribution, and I hoped it =
would make C/S mode work...
But it doesn't, I'm still getting Exceptions when two threads try to =
access the repository (read) at the same time.
This is the new stack trace:
-------------------------------------------------------------------------=
-----
[ODMG] ERROR: Caught EOFException while reading the stream header
Caught EOFException while reading the stream header
at =
ojb.broker.server.PersistenceBrokerClient.callServer(PersistenceBroke
rClient.java:115)
at =
ojb.broker.server.PersistenceBrokerClient.callServer(PersistenceBroke
rClient.java:55)
at =
ojb.broker.server.PersistenceBrokerClient.beginTransaction(Persistenc
eBrokerClient.java:160)
at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:225)
at =
charlie.ojb.ProyectoManagerOJB.getEmpleado(ProyectoManagerOJB.java:39
0)
at charlie.web.LogonAction.perform(LogonAction.java:49)
at =
org.apache.struts.action.ActionServlet.processActionPerform(ActionSer
vlet.java:1786)
at =
org.apache.struts.action.ActionServlet.process(ActionServlet.java:158
5)
at =
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at =
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at =
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:201)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2344)
at =
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:164)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
462)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:163)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1011)
at =
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1106)
at java.lang.Thread.run(Unknown Source)
-------------------------------------------------------------------------=
-----
***
I usually get this stack trace the first time I try to access =
concurrently.
From then on, I get this stack trace:
-------------------------------------------------------------------------=
-----
[ODMG] ERROR: null
org.odmg.TransactionInProgressException
<<no stack trace available>>
org.odmg.QueryException
at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:250)
at =
charlie.ojb.ProyectoManagerOJB.getEmpleado(ProyectoManagerOJB.java:39
0)
at charlie.web.LogonAction.perform(LogonAction.java:49)
at =
org.apache.struts.action.ActionServlet.processActionPerform(ActionSer
vlet.java:1786)
at =
org.apache.struts.action.ActionServlet.process(ActionServlet.java:158
5)
at =
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at =
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at =
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:201)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2344)
at =
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:164)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
462)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:163)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1011)
at =
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1106)
at java.lang.Thread.run(Unknown Source)
-------------------------------------------------------------------------=
-----
Please help me make OJB work in a multithreading scenario (website: =
Struts + JDO). I need to deploy these week, but if I can't make the =
persistance layer work in a multithreading scenario, I'll have to code =
everything in JDBC again... and you know, that's incredibly fun!
Thanks in advance
Ricardo Arguello
|
|
From: Doug C. <de...@fl...> - 2002-02-02 22:53:26
|
A broker pool is required to implement odmg concurrent transactions
effectively. Daniel Fernandez, you have been looking at a broker pool
implementation; have you also thought about how to use this pool at
the odmg level in single vm mode?
Having looked at this a bit, it seems to me that one broker per odmg
transaction is a logical way to proceed. Most code that needs to
reference a broker is also grabbing a reference to a transaction.
Unfortunately a 1-1 relationship between DatabaseImpl and broker in
the current code is assumed by OJB.getBroker, but this can be fixed
pretty easily I think. Many places that get a broker from OJB either
can just as easily get it from the transaction, or don't care what
broker they end up with since they are just using it for access to the
cache or metadata.
For example, sequences such as (e.g., OQLQueryImpl.execute):
// retrieve a broker instance
PersistenceBroker broker = OJB.getInstance().getBroker();
//obtain current ODMG transaction
Transaction tx = OJB.getInstance().currentTransaction();
// we allow queries even if no ODMG transaction is running.
// thus we have to provide a pseudo tx if necessary
boolean needsCommit = false;
if (tx == null)
{
tx = OJB.getInstance().newTransaction();
}
// we allow to work with unopened transactions.
// we assume that such a tx is to be closed after performing the query
if (!tx.isOpen())
{
tx.begin();
needsCommit = true;
}
would get the trasaction first and become
//obtain current ODMG transaction
Transaction tx = OJB.getInstance().currentTransaction();
// we allow queries even if no ODMG transaction is running.
// thus we have to provide a pseudo tx if necessary
boolean needsCommit = false;
if (tx == null)
{
tx = OJB.getInstance().newTransaction();
}
// we allow to work with unopened transactions.
// we assume that such a tx is to be closed after performing the query
if (!tx.isOpen())
{
tx.begin();
needsCommit = true;
}
// retrieve the transactions's broker instance
PersistenceBroker broker = tx.getBroker(); // THE CHANGE
If you need a hand with this let me know. I am interested in seeing
the omdg layer improved with more concurrency for single vm
applications.
e
|
|
From: Doug C. <de...@fl...> - 2002-02-02 17:51:15
|
Hello Thomas, Saturday, February 02, 2002, 6:35:51 AM, you wrote: <snip> TM> Hmm. If you are NOT using "read-uncommited" and there is no TM> READ-lock in the LockMap it must be a bug! Which isolation level TM> are you using for class Article ? In two tests I used: <MappingRepository isolation="repeatable-read"> as well as the usual repository.xml; both gave the same results. So yes, I think there's a bug. TM> Maybe we need different semantics for the isolation levels? Did you have TM> a look at my doc concerning the LockManager? It contains a table TM> demonstrating the behaviour of all isolation levels currently implemented. I will look at it more closely. I've hestitated to use the default read-uncommited isolation level because I don't understand the implications of the semantics. It's one thing to have transactions overlap; it's quite another to read a partially modified object. I am not that brave! Regards, e |
|
From: Thomas M. <tho...@ho...> - 2002-02-02 11:52:59
|
Hi Jakob,
Thanks for your latest contribution. I hope to get it worked into the
next release!
Thomas
Jakob Braeuchi wrote:
> hi,
>
> the attached zip contains some code based on version 0.7.310 to support
> optimistic locking for int, long and timestamp fields.
>
> <FieldDescriptor id="6">
> <field.name>test</field.name>
> <column.name>test</column.name>
> <jdbc_type>INTEGER</jdbc_type>
> <locking>true</locking>
> </FieldDescriptor>
> <FieldDescriptor id="8">
> <field.name>lastModified</field.name>
> <column.name>entryDate</column.name>
> <jdbc_type>TIMESTAMP</jdbc_type>
> <locking>true</locking>
> </FieldDescriptor>
>
> the locking fields are used in the where-clause for update and delete. if
> the rowcount of the update is 0, an exception is thrown
> (JdbcAccess::executeUpdate()) :
> ...
> broker.getStatementManager().bindUpdate(stmt, mif, obj);
> if (stmt.executeUpdate() == 0 && mif.isLocking()) //BRJ
> {
> throw new PersistenceBrokerException("Object has been modified by
> someone else");
> }
> ...
>
> hth
> jakob
>
|
|
From: Thomas M. <tho...@ho...> - 2002-02-02 11:38:54
|
Hi Doug, Doug Currie wrote: > TM> Here is my argument why OJB still meets the requirements: > > TM> During tx commit OJB automatically upgrades Locks for objects that only > TM> have a READ lock. So we obtain WRITE locks implicitely for modified > TM> objects. ODMG does not specify at which point in time the WRITE lock is > TM> to be acquired! ;-) > > I might buy this if > a) the READ locks were obtained implicitly, and READ locks are obtained implicitely during OqlQueryImpl.execute() and (after the latest bug fix also) in DatabaseImpl.lookup(...). But: for "read-uncommited" no LockEntries are placed into the LockMap. The semantics of "read-uncommited" as implemented now is "you are always allowed to read". Maybe we have to modify this semantics? > b) the isolation mode is read-uncommitted Hmm. If you are NOT using "read-uncommited" and there is no READ-lock in the LockMap it must be a bug! Which isolation level are you using for class Article ? Maybe we need different semantics for the isolation levels? Did you have a look at my doc concerning the LockManager? It contains a table demonstrating the behaviour of all isolation levels currently implemented. > > Neither of these is true in my example. > > TM> One of the next things we implement is optimistic locking (similar to > TM> the TOPLink approach). > > Yes, this would be nice; a version number or timestamp would be needed > on each object to see if the current version on disk matches the > version modified by the transaction. > Jakob just posted his Optimistic locking solution to the developer list I will integrate it asap. > TM> If an application uses optimistic locking your argument is not longer > TM> valid, as collision-detection is delayed until RDBMS access during tx > TM> commit. > > The problem remains that transaction isolation is violated since an > object can be modified by multiple transactions since there is only > one version in the cache. I believe this problem could be solved if we reconstitute the original state of objects during tx.abort(). Your /*6*/ would not return a modified value then! JDO fixes this by having many copies of the > same object in memory, one per writer. This breaks java object > identity, so they invented "JDO identity." > > TM> So I cannot see why OJB should not be compliant to the implicit locking > TM> feature! > > As long as there are versions/timestamps and many copies of the > same object in memory, one per writer. > > TM> There are also some "lazy" implementors (e.g. Objectivity) that require > TM> the user to place locking code into getter and setter methods. > > TM> I think this is a valid approach, as the intrusion into user code is > TM> minimal. > > It is worth considering. > > TM> Currently I favour the following implementation strategy for OJB-JDO: > TM> Reuse (or make a clearroom rewrite) of those aspects of SUNs JDO > TM> Reference Implementation (RI), that are related to Lifecycle, > TM> Codeenhancement etc. > > The current RI enhancer generates source code, and is non-compliant. > > TM> And simply write a com.sun.jdori.StoreManager implementation that > TM> parallels the com.sun.jdori.fostore.FOStoreStoreManager but uses a OJB > TM> PersistenceBroker to perform persistence operations. > > I suspect you may also want to consider: > - using some of the current odmg locking stuff > - using some of the current odmg ObjectEnvelope stuff > - making ojb.broker's repository.xml syntax more compatible with jdo > (or adding an alternate syntax there) > Yes, but only in a second step. The first step will be to plugin a PersistenceBroker based StoreManager into JDORI. There are many people that doubt that a OJB-JDO implementation can be build with relatively few efforts that I think it's good to have a working prototype as a source of inspiration. cu, Thomas > Regards, > > e > > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Jakob B. <jbr...@ho...> - 2002-02-02 11:06:54
|
hi, the code sent in the previous mail has an error in the method bindDelete(PreparedStatement stmt, ClassDescriptor cld, Object obj) of StatementManager. sorry jakob |
|
From: Jakob B. <jbr...@ho...> - 2002-02-02 10:07:08
|
hi,
the attached zip contains some code based on version 0.7.310 to support
optimistic locking for int, long and timestamp fields.
<FieldDescriptor id="6">
<field.name>test</field.name>
<column.name>test</column.name>
<jdbc_type>INTEGER</jdbc_type>
<locking>true</locking>
</FieldDescriptor>
<FieldDescriptor id="8">
<field.name>lastModified</field.name>
<column.name>entryDate</column.name>
<jdbc_type>TIMESTAMP</jdbc_type>
<locking>true</locking>
</FieldDescriptor>
the locking fields are used in the where-clause for update and delete. if
the rowcount of the update is 0, an exception is thrown
(JdbcAccess::executeUpdate()) :
...
broker.getStatementManager().bindUpdate(stmt, mif, obj);
if (stmt.executeUpdate() == 0 && mif.isLocking()) //BRJ
{
throw new PersistenceBrokerException("Object has been modified by
someone else");
}
...
hth
jakob
|
|
From: <ri...@ya...> - 2002-02-01 22:17:06
|
Hello,
I have tried the C/S patch, and I am getting this exception when two =
users try to login at the same time:
-------------------------------------------------------------
[ODMG] ERROR: null
org.odmg.TransactionNotInProgressException
at =
ojb.broker.server.PersistenceBrokerClient.commitTransaction(Persisten
ceBrokerClient.java:192)
at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:230)
at =
charlie.ojb.ProyectoManagerOJB.getEmpleado(ProyectoManagerOJB.java)
at charlie.web.LogonAction.perform(LogonAction.java)
at =
org.apache.struts.action.ActionServlet.processActionPerform(ActionSer
vlet.java:1787)
at =
org.apache.struts.action.ActionServlet.process(ActionServlet.java:158
6)
at =
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:510)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at =
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:247)
at =
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
at =
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:243)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:201)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2344)
at =
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:164)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:170)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
462)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:564)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:163)
at =
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
.java:566)
at =
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:472)
at =
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at =
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
r.java:1011)
at =
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
va:1106)
at java.lang.Thread.run(Thread.java:484)
-------------------------------------------------------------------------=
One of the users logs in, the other gets a stack trace.
I'm sure is not the singleton trying to initialize the omdg variable =
twice, because I'm using the "double check idiom".
These are the messages in the OJB C/S console:
[ojb.broker.server.RequestProcessor] ERROR: Client tries to open tx =
twice
[ojb.broker.server.RequestProcessor] ERROR: =
ojb.broker.server.Request@e35d5
[ojb.broker.server.RequestProcessor] ERROR: null
[ojb.broker.server.RequestProcessor] ERROR: null
[ojb.broker.server.RequestProcessor] ERROR: Client tries to open tx =
twice
[ojb.broker.server.RequestProcessor] ERROR: Client tries to open tx =
twice
Thanks for the Struts + OJB sample code. It's very interesting how he =
passes values between Actions and OJB, using a Hashtable.
Please let me know what to do next...
Thanks A LOT for all your help!
Ricardo Arguello
----- Original Message -----=20
From: "Thomas Mahler" <tho...@ho...>
To: "Ricardo Arg=FCello" <ri...@ya...>
Cc: "ojb" <obj...@li...>
Sent: Friday, February 01, 2002 2:48 PM
Subject: Re: [OJB-developers] Re: OJB in C/S mode: =
TransactionInProgressEx
Hi Ricardo
attached you'll find the struts sample and a patch for the BrokerPool
(for c/s) mode.
Ricardo Arg=FCello wrote:
> Hello,
>
> As I said before, when 2 users try to use the same part of the
"manager", one of them gets an Exception, the other process it =
correctly.
>
> Maybe it's because of the fact that I'm using ONE "odmg instance"
(odmg=3DOJB.getInstance()) in my manager singleton. In every invocation =
of
a function in this manager, I use:
> Transaction tx =3D odmg.newTransaction()
>
> So, aparently it's not a problem. But I'm not sure...
It's no problem. OJB.getInstance() always returns the same instance...
>
> This is the complete stack trace, when 2 users access the same =
function:
>=20
-------------------------------------------------------------------------=
> [ODMG] ERROR: null
> org.odmg.QueryException
> at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:251)
> at
charlie.ojb.ProyectoManagerOJB.tareasPorEmpleado(ProyectoManagerOJB.j
> ava)
unfortunately we don't see what's going wrong within the OQL query.
Please set the loglevel for ODMG and PersistenceBrokerImpl to DEBUG and
send me the result to get a clearer impression...
>
>
> I'm NOT using OJB in C/S mode. The "TransactionInProgressException
problem" was related to OJB in C/S mode, this one is ANOTHER problem, as
you can see in the satck trace.
>
> I hope the patch helps solucionate the C/S problem, but this one
seems to be another issue, am I right?
>
Yes, I think so. Please try out the patched c/s mode
HTH,
Thomas
> Thanks for your help!
>
>
> Greetings,
>
>
>
> Ricardo Arguello
> ri...@ya...
>
>
>
>
>
>
> ----- Original Message -----
> From: "Mahler Thomas" <tho...@it...>
> To: "'Ricardo Arg=FCello'" <ri...@ya...>; "ojb"
<obj...@li...>
> Sent: Thursday, January 31, 2002 8:04 AM
> Subject: AW: [OJB-developers] Re: OJB in C/S mode:
TransactionInProgressEx
>
>
> Hi again Ricardo,
>
> The bugfix is on the way. I hope to get it posted today!
>
>
>>-----Urspr=FCngliche Nachricht-----
>>Von: Ricardo Arg=FCello [mailto:ri...@ya...]
>>Gesendet: Mittwoch, 30. Januar 2002 22:43
>>An: ojb
>>Betreff: Re: [OJB-developers] Re: OJB in C/S mode:
>>TransactionInProgressEx
>>
>>
>>Hello,
>>
>>Thanks for your reply.
>>
>>I have a "manager class" wich is called from my Struts
>>actions, and it does al the work, calling the "OJBed
>>classes", retuning Collections, etc.
>>
>>This manager is a singleton, and when I instanciate it (only
>>once) I initialize the "odmg" class variable:
>>
>>public class ProyectoManagerOJB {
>> private static final String databaseName =3D
>>
>>PersistenceBrokerFactory.getConfiguration().getRepositoryFilename();
>>
>> private Implementation odmg; // maybe this is wrong!
>>
>
> This absolutely ok. OJB.getInstance() is a singleton
>
>
>> public ProyectoManagerOJB() {
>> odmg =3D OJB.getInstance();
>> Database db =3D odmg.newDatabase();
>> try {
>> db.open(databaseName, Database.OPEN_READ_WRITE);
>> } catch (ODMGException ex) {
>> ex.printStackTrace();
>> }
>> }
>>...
>>}
>>
>>Struts actions call functions in this class:
>>
>>ProyectoManager pm =3D ProyectoManager.getInstance(); // it's
>>an abstract factory, returns ProyectoManagerOJB
>>User user =3D pm.getUser("john");
>>
>>The corresponding class in ProyectoManagerOJB is this one:
>>(User is an interface, UserOJB implements it)
>>
>>public User getUser(String user) {
>> try {
>> Transaction tx =3D odmg.newTransaction();
>> tx.begin();
>> OQLQuery query =3D odmg.newOQLQuery();
>> query.create(
>> "select p from "
>> + charlie.ojb.UserOJB.class.getName()
>> + " where user =3D \""
>> + user
>> + "\"");
>> DList result =3D (DList) query.execute();
>> User user =3D (User) result.get(0);
>> tx.commit();
>> return user;
>> } catch (Exception e) {
>> e.printStackTrace();
>> return null;
>> }
>>}
>>
>>As you can see, in getUser() I use the class variable "odmg".
>>
>
> That's OK!
>
>
>>If I have two users login in, I get a =
TransactionInProgressException.
>>
>
> Please send me a complete stacktrace of this exception. I'm not sure
if it
> is a PersistenceBrokerException or an ODMGException.
>
>
>>I believe it is because of the fact that odmg is an instance =
variable.
>>
>>So, could you send me some code examples of your
>>friends'"odmg helper class" to see how I could implement it
>>in my architecture?
>>
>>
>
> I'll will post it to you later this day.
>
>
>>Thanks in advance!
>>
>>Greetings from Quito, Ecuador
>>
>>
>
> greetings from Essen, Germany
>
> Thomas
>
>
>>Ricardo Arguello
>>ri...@ya...
>>
>>
>>----- Original Message -----
>>From: "Thomas Mahler" <tho...@ho...>
>>To: "Ricardo Arguello" <ri...@ya...>; "ojb"
>><obj...@li...>
>>Sent: Wednesday, January 30, 2002 3:35 PM
>>Subject: [OJB-developers] Re: OJB in C/S mode: =
TransactionInProgressEx
>>
>>
>>
>>>Hi Ricardo,
>>>
>>>sorry for the trouble OJB is causing for you.
>>> We'll try to get a solution for this soon.
>>>
>>>Ricardo Arguello wrote:
>>>
>>>
>>>>Hello,
>>>>
>>>>As I said before, I'm getting a
>>>>TransactionInProgressException when I use OJB in
>>>>Client/Server mode.
>>>>
>>>>I tried changing the log to DEBUG, bit it imposibe for me
>>>>to distinguish any of the errors, there is a LOT of DEBUG
>>>>messages, of the following style:
>>>>
>>>>
>>>
>>>
>>>Yup, sometimes it's hard to know which part of the system
>>>
>>might write
>>
>>>the relevant log infos...
>>>
>>>
>>>
>>>>[ojb.broker.server.RequestProcessor] DEBUG: OJB
>>>>RequestProcessor 2 waiting...
>>>>[ojb.broker.server.RequestProcessor] DEBUG: OJB
>>>>RequestProcessor 7 working...
>>>>[ojb.broker.server.RequestProcessor] DEBUG: dispatching [24,
>>>>[ojb.broker.server.RequestProcessor] DEBUG: -1,
>>>>[ojb.broker.server.RequestProcessor] DEBUG: class
>>>>charlie.ojb.EmpleadoOJB,
>>>>[ojb.broker.server.RequestProcessor] DEBUG: null]
>>>>[ojb.broker.server.BrokerPool] DEBUG: getFreeBrokerId: 1,
>>>>remaining: [1, 1, 1, 1
>>>>, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 3,
>>>>1, 1, 1, 1, 1, 1, 3,
>>>>1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1
>>>>, 1, 1, 4, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 5, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 6, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 7, 1, 1, 1, 8,
>>>>1, 1, 1, 9, 1, 1, 9, 1
>>>>, 1, 1, 1, 1, 1, 0, 1, 9, 1, 1, 1, 1, 9, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>> 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1
>>>>, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
>>>>
>>>>
>>>>Awful, right?
>>>>
>>>
>>>Yes that's awful to read. But it is also a clear indicator
>>>
>>that there
>>
>>>must be a bug in the BrokerPool. It should contain exactly
>>>
>>ten brokers
>>
>>>numbered from 0 - 9.
>>>As the list you see contains a lot of "1" entries you are
>>>
>>served with
>>
>>>the same broker instance for multiple transactions.
>>>
>>>This is definitely a severe bug.
>>>
>>>I will start working on it asap and hope to have a fix by
>>>
>>the weekend.
>>
>>>
>>>>I cannot find the errors I metioned in my previous
>>>>message... But my application stil acts the same: Two
>>>>persons can't even login at the same time, one of them gets
>>>>a stack trace...
>>>>
>>>>
>>>
>>>I assume that it is all related to the above error !
>>>
>>>
>>>
>>>>I was reading the Locking document, and I tried to add a
>>>>isolation=3D"read-uncommitted" to all my class definitions in
>>>>the repository.xml file, but tha doesn't help either.
>>>>
>>>
>>>This is definitely a locking problem. OJB uses read-uncommited by
>>>default already. In the case of locking problems you would
>>>
>>get a ODMG
>>
>>>LockNotGrantedException!
>>>
>>>
>>>>How
>>>>should I declare my lockings? In the XML file, in my code
>>>>(you say the ODMG doesnt dictate a way to that).
>>>>
>>>>
>>>
>>>Locking is declared in the repository only. ODMG specifies
>>>
>>no API for
>>
>>>setting locklevels.
>>>
>>>
>>>
>>>>Please clarify this to me? Do I need to do C/S to use OJB
>>>>in a web application?
>>>>
>>>
>>>
>>>Hmm. I know of people who are using OJB in singlevm mode in
>>>
>>Web apps.
>>
>>>As long as the commit phase of ODMG transactions is
>>>
>>relatively short
>>
>>>there won't be much problems.
>>>
>>>I'm intending to have brokerpool for the singlevm mode too.
>>>
>>then it will
>>
>>> be totally safe to use the singlevm mode which is much faster !!!
>>>
>>>
>>>
>>>>Wouldn't a "OJB Helper" with a single Database instance
>>>>(singleton) be enough?
>>>>
>>>>
>>>
>>>Yes that should be sufficient.
>>>
>>>
>>>
>>>>If that's the case, how could I implement that?
>>>>
>>>
>>>Hmm, I'm not quite sure what you want to implement exactly?
>>>
>>>
>>>
>>>>Is OJB thread safe?
>>>>
>>>
>>>Yes
>>>
>>>
>>>>How can I use OJB with Tomcat + Struts?
>>>>
>>>
>>>A colleague of mine used Struts and the OJB ODMG api sucessfully.
>>>He defined special STruts actions that used ODMG
>>>
>>transactions to do the
>>
>>>persistence work. It's pretty straightforward.
>>>
>>>If you are interested I might post you sample code for this.
>>>
>>>
>>>
>>>>How can I assure that 2 transactions can READ at the same
>>>>time, without locking?
>>>>
>>>>
>>>
>>>Currently the OJB ODMG implementation relies on pessimistic =
locking.
>>>There is currently no optimistic locking support. (will be
>>>
>>there in 1.0)
>>
>>>But if you use "uncommitted-read" there should be no
>>>
>>locking problems.
>>
>>>You can do even more do avoid lock conflicts through WRITE
>>>
>>operations.
>>
>>>In OJB.properties you'll find an entry LockAssociations set
>>>
>>this to READ.
>>
>>>The LockAssociations entry defines the behaviour for the OJB
>>>implicit locking feature. If set to WRITE (default)
>>>
>>acquiring a write-
>>
>>>lock on a given object x implies write locks on all objects
>>>
>>associated
>>
>>>to x. If set to READ implicit read-locks are acquired.
>>>Acquiring a read-lock on x thus allways results in implicit
>>>
>>read-locks
>>
>>>on all associated objects.
>>>
>>>Using uncommited reads in combination with
>>>
>>LockAssociation=3DREAD will
>>
>>>reduce Locking related problems to a minimum.
>>>
>>>But as I said before: your problem is NOT related to locking.
>>>
>>>
>>>
>>>>Thanks in advance.
>>>>
>>>>Ricardo Arguello (an ex-Castor refugee)
>>>>
>>>
>>>I'll work hard to ensure you won't become an OJB refugee ;-)
>>>
>>>
>>>cu,
>>>
>>>Thomas
>>>
>>>
>>>
>>>_______________________________________________
>>>Objectbridge-developers mailing list
>>>Obj...@li...
=
>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>
>>>
>>
>>
>>_______________________________________________
>>Objectbridge-developers mailing list
>>Obj...@li...
>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>
>>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
|
|
From: Doug C. <de...@fl...> - 2002-02-01 20:45:37
|
TM> Here is my argument why OJB still meets the requirements: TM> During tx commit OJB automatically upgrades Locks for objects that only TM> have a READ lock. So we obtain WRITE locks implicitely for modified TM> objects. ODMG does not specify at which point in time the WRITE lock is TM> to be acquired! ;-) I might buy this if a) the READ locks were obtained implicitly, and b) the isolation mode is read-uncommitted Neither of these is true in my example. TM> One of the next things we implement is optimistic locking (similar to TM> the TOPLink approach). Yes, this would be nice; a version number or timestamp would be needed on each object to see if the current version on disk matches the version modified by the transaction. TM> If an application uses optimistic locking your argument is not longer TM> valid, as collision-detection is delayed until RDBMS access during tx TM> commit. The problem remains that transaction isolation is violated since an object can be modified by multiple transactions since there is only one version in the cache. JDO fixes this by having many copies of the same object in memory, one per writer. This breaks java object identity, so they invented "JDO identity." TM> So I cannot see why OJB should not be compliant to the implicit locking TM> feature! As long as there are versions/timestamps and many copies of the same object in memory, one per writer. TM> There are also some "lazy" implementors (e.g. Objectivity) that require TM> the user to place locking code into getter and setter methods. TM> I think this is a valid approach, as the intrusion into user code is TM> minimal. It is worth considering. TM> Currently I favour the following implementation strategy for OJB-JDO: TM> Reuse (or make a clearroom rewrite) of those aspects of SUNs JDO TM> Reference Implementation (RI), that are related to Lifecycle, TM> Codeenhancement etc. The current RI enhancer generates source code, and is non-compliant. TM> And simply write a com.sun.jdori.StoreManager implementation that TM> parallels the com.sun.jdori.fostore.FOStoreStoreManager but uses a OJB TM> PersistenceBroker to perform persistence operations. I suspect you may also want to consider: - using some of the current odmg locking stuff - using some of the current odmg ObjectEnvelope stuff - making ojb.broker's repository.xml syntax more compatible with jdo (or adding an alternate syntax there) Regards, e |
|
From: Thomas M. <tho...@ho...> - 2002-02-01 19:50:26
|
Hi Doug, hi all, Doug Currie wrote: > > Based on my experience with object databases, it surprises me that ojb > can be considered "fully ODMG 3.0 compliant." Oops, it should read: "almost fully ODMG 3.0 compliant" ;-) > I must admit that I do > not have a copy of the ODMG 3.0 spec at hand (is there a freely > downloadable copy on the web?). No, they want you to buy a copy ;-) > I do have the JDO spec, though, and > this same issue will certainly need to be addressed before a JDO > compliant implementation can be completed, so I am reporting it here. > > The problem is: implicit locking doesn't work. > > BTW, I am not advocating changing ojb to correct this problem, but > implicit locking should not be communicated to users as a feature, and > claims about compliance should be made with caveats. > You are right. It is not good to claim features as implemented that are not there. The success of an OpenSource tool does not rely on marketing slogans! The best thing is to frankly say if something is not implemented. As there is no ODMG compatibility test suite it is not always easy to decide what is required to have a compliant implementation. > Consider the following comments from interface org.odmg.Transaction: > * Read locks are implicitly obtained on objects as they are accessed. > * Write locks are implicitly obtained as objects are modified. > Hmm. you are right this is definitely not implemented. Objects are implicitely READ-locked during lookups. Objects are implicitely WRITE-locked during transaction commit if they had not been WRITE-locked before. Here is my argument why OJB still meets the requirements: During tx commit OJB automatically upgrades Locks for objects that only have a READ lock. So we obtain WRITE locks implicitely for modified objects. ODMG does not specify at which point in time the WRITE lock is to be acquired! ;-) ODMG 3.0 (Java Binding) does not specify any locking strategy: "An object management system (ODBM) might permit optimistic, pessimistic, or other locking paradigms; ODMG does not specify this." (p. 252) So we are free to choose a locking strategy and we are definitely not obliged to support a bulletproof pessimistic locking. ;-) One of the next things we implement is optimistic locking (similar to the TOPLink approach). If an application uses optimistic locking your argument is not longer valid, as collision-detection is delayed until RDBMS access during tx commit. So I cannot see why OJB should not be compliant to the implicit locking feature! BUT: of course you are absolutely right to mention these issues! There is no implicit PESSIMISTIC locking in OJB! And we should make this point very clear in the documentation. (Or even better find a real solution). What do you think ? <snip> I appreciate that you are using a testCase to communicate the problem. This very helpful! </snip> > > The moral of the story is that ojb does not support implicit locks > correctly. A user must use explicit locking for reads and writes > before accessing or modifying an object, respectively. > Yes. to work safely with PESSIMISTIC locks the user must use explicit WRITE locks ! > Most ODMG Java implementations do implicit locking by either: > - using a custom JVM > and requiring persistent classes to be registered > and/or.. > - modifying persistent classes' > source code or .class files to intercept accesses > and making all persistent fields private > Right. But I don't think that these are clean solutions. IMHO the REAL problem is that Java does not support AOP (Aspect Oriented Programming) techniques to allow the dynamic mixin of the required code into business objects. Things could be MUCH simpler! There are also some "lazy" implementors (e.g. Objectivity) that require the user to place locking code into getter and setter methods. I think this is a valid approach, as the intrusion into user code is minimal. > In order to support "transparent persistence" AND implicit locking it > would be necessary to modify any class which accesses a persistent > class's fields. > > JDO does require implicit locking, and uses a class "enhancer" to make > it work. The reference implementation produces replacement java source > code for peristent classes, and so does not completely implement the > specification. A better approach would be to implement a custom class > loader to "enhance" the persistent classes at load time. > Currently I favour the following implementation strategy for OJB-JDO: Reuse (or make a clearroom rewrite) of those aspects of SUNs JDO Reference Implementation (RI), that are related to Lifecycle, Codeenhancement etc. And simply write a com.sun.jdori.StoreManager implementation that parallels the com.sun.jdori.fostore.FOStoreStoreManager but uses a OJB PersistenceBroker to perform persistence operations. best regards, Thomas -- OJB Headquarters, Essen, Germany > Regards, > > e > |
|
From: Thomas M. <tho...@ho...> - 2002-02-01 19:50:10
|
Hi Ricardo
attached you'll find the struts sample and a patch for the BrokerPool
(for c/s) mode.
Ricardo Arg=FCello wrote:
> Hello,
>
> As I said before, when 2 users try to use the same part of the
"manager", one of them gets an Exception, the other process it correctly.
>
> Maybe it's because of the fact that I'm using ONE "odmg instance"
(odmg=3DOJB.getInstance()) in my manager singleton. In every invocation o=
f
a function in this manager, I use:
> Transaction tx =3D odmg.newTransaction()
>
> So, aparently it's not a problem. But I'm not sure...
It's no problem. OJB.getInstance() always returns the same instance...
>
> This is the complete stack trace, when 2 users access the same functi=
on:
>=20
-------------------------------------------------------------------------
> [ODMG] ERROR: null
> org.odmg.QueryException
> at ojb.odmg.oql.OQLQueryImpl.execute(OQLQueryImpl.java:251)
> at
charlie.ojb.ProyectoManagerOJB.tareasPorEmpleado(ProyectoManagerOJB.j
> ava)
unfortunately we don't see what's going wrong within the OQL query.
Please set the loglevel for ODMG and PersistenceBrokerImpl to DEBUG and
send me the result to get a clearer impression...
>
>
> I'm NOT using OJB in C/S mode. The "TransactionInProgressException
problem" was related to OJB in C/S mode, this one is ANOTHER problem, as
you can see in the satck trace.
>
> I hope the patch helps solucionate the C/S problem, but this one
seems to be another issue, am I right?
>
Yes, I think so. Please try out the patched c/s mode
HTH,
Thomas
> Thanks for your help!
>
>
> Greetings,
>
>
>
> Ricardo Arguello
> ri...@ya...
>
>
>
>
>
>
> ----- Original Message -----
> From: "Mahler Thomas" <tho...@it...>
> To: "'Ricardo Arg=FCello'" <ri...@ya...>; "ojb"
<obj...@li...>
> Sent: Thursday, January 31, 2002 8:04 AM
> Subject: AW: [OJB-developers] Re: OJB in C/S mode:
TransactionInProgressEx
>
>
> Hi again Ricardo,
>
> The bugfix is on the way. I hope to get it posted today!
>
>
>>-----Urspr=FCngliche Nachricht-----
>>Von: Ricardo Arg=FCello [mailto:ri...@ya...]
>>Gesendet: Mittwoch, 30. Januar 2002 22:43
>>An: ojb
>>Betreff: Re: [OJB-developers] Re: OJB in C/S mode:
>>TransactionInProgressEx
>>
>>
>>Hello,
>>
>>Thanks for your reply.
>>
>>I have a "manager class" wich is called from my Struts
>>actions, and it does al the work, calling the "OJBed
>>classes", retuning Collections, etc.
>>
>>This manager is a singleton, and when I instanciate it (only
>>once) I initialize the "odmg" class variable:
>>
>>public class ProyectoManagerOJB {
>> private static final String databaseName =3D
>>
>>PersistenceBrokerFactory.getConfiguration().getRepositoryFilename();
>>
>> private Implementation odmg; // maybe this is wrong!
>>
>
> This absolutely ok. OJB.getInstance() is a singleton
>
>
>> public ProyectoManagerOJB() {
>> odmg =3D OJB.getInstance();
>> Database db =3D odmg.newDatabase();
>> try {
>> db.open(databaseName, Database.OPEN_READ_WRITE);
>> } catch (ODMGException ex) {
>> ex.printStackTrace();
>> }
>> }
>>...
>>}
>>
>>Struts actions call functions in this class:
>>
>>ProyectoManager pm =3D ProyectoManager.getInstance(); // it's
>>an abstract factory, returns ProyectoManagerOJB
>>User user =3D pm.getUser("john");
>>
>>The corresponding class in ProyectoManagerOJB is this one:
>>(User is an interface, UserOJB implements it)
>>
>>public User getUser(String user) {
>> try {
>> Transaction tx =3D odmg.newTransaction();
>> tx.begin();
>> OQLQuery query =3D odmg.newOQLQuery();
>> query.create(
>> "select p from "
>> + charlie.ojb.UserOJB.class.getName()
>> + " where user =3D \""
>> + user
>> + "\"");
>> DList result =3D (DList) query.execute();
>> User user =3D (User) result.get(0);
>> tx.commit();
>> return user;
>> } catch (Exception e) {
>> e.printStackTrace();
>> return null;
>> }
>>}
>>
>>As you can see, in getUser() I use the class variable "odmg".
>>
>
> That's OK!
>
>
>>If I have two users login in, I get a TransactionInProgressException.
>>
>
> Please send me a complete stacktrace of this exception. I'm not sure
if it
> is a PersistenceBrokerException or an ODMGException.
>
>
>>I believe it is because of the fact that odmg is an instance variable.
>>
>>So, could you send me some code examples of your
>>friends'"odmg helper class" to see how I could implement it
>>in my architecture?
>>
>>
>
> I'll will post it to you later this day.
>
>
>>Thanks in advance!
>>
>>Greetings from Quito, Ecuador
>>
>>
>
> greetings from Essen, Germany
>
> Thomas
>
>
>>Ricardo Arguello
>>ri...@ya...
>>
>>
>>----- Original Message -----
>>From: "Thomas Mahler" <tho...@ho...>
>>To: "Ricardo Arguello" <ri...@ya...>; "ojb"
>><obj...@li...>
>>Sent: Wednesday, January 30, 2002 3:35 PM
>>Subject: [OJB-developers] Re: OJB in C/S mode: TransactionInProgressE=
x
>>
>>
>>
>>>Hi Ricardo,
>>>
>>>sorry for the trouble OJB is causing for you.
>>> We'll try to get a solution for this soon.
>>>
>>>Ricardo Arguello wrote:
>>>
>>>
>>>>Hello,
>>>>
>>>>As I said before, I'm getting a
>>>>TransactionInProgressException when I use OJB in
>>>>Client/Server mode.
>>>>
>>>>I tried changing the log to DEBUG, bit it imposibe for me
>>>>to distinguish any of the errors, there is a LOT of DEBUG
>>>>messages, of the following style:
>>>>
>>>>
>>>
>>>
>>>Yup, sometimes it's hard to know which part of the system
>>>
>>might write
>>
>>>the relevant log infos...
>>>
>>>
>>>
>>>>[ojb.broker.server.RequestProcessor] DEBUG: OJB
>>>>RequestProcessor 2 waiting...
>>>>[ojb.broker.server.RequestProcessor] DEBUG: OJB
>>>>RequestProcessor 7 working...
>>>>[ojb.broker.server.RequestProcessor] DEBUG: dispatching [24,
>>>>[ojb.broker.server.RequestProcessor] DEBUG: -1,
>>>>[ojb.broker.server.RequestProcessor] DEBUG: class
>>>>charlie.ojb.EmpleadoOJB,
>>>>[ojb.broker.server.RequestProcessor] DEBUG: null]
>>>>[ojb.broker.server.BrokerPool] DEBUG: getFreeBrokerId: 1,
>>>>remaining: [1, 1, 1, 1
>>>>, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 3,
>>>>1, 1, 1, 1, 1, 1, 3,
>>>>1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1
>>>>, 1, 1, 4, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 5, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 6, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 7, 1, 1, 1, 8,
>>>>1, 1, 1, 9, 1, 1, 9, 1
>>>>, 1, 1, 1, 1, 1, 0, 1, 9, 1, 1, 1, 1, 9, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>> 1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1
>>>>, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1,
>>>>1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
>>>>
>>>>
>>>>Awful, right?
>>>>
>>>
>>>Yes that's awful to read. But it is also a clear indicator
>>>
>>that there
>>
>>>must be a bug in the BrokerPool. It should contain exactly
>>>
>>ten brokers
>>
>>>numbered from 0 - 9.
>>>As the list you see contains a lot of "1" entries you are
>>>
>>served with
>>
>>>the same broker instance for multiple transactions.
>>>
>>>This is definitely a severe bug.
>>>
>>>I will start working on it asap and hope to have a fix by
>>>
>>the weekend.
>>
>>>
>>>>I cannot find the errors I metioned in my previous
>>>>message... But my application stil acts the same: Two
>>>>persons can't even login at the same time, one of them gets
>>>>a stack trace...
>>>>
>>>>
>>>
>>>I assume that it is all related to the above error !
>>>
>>>
>>>
>>>>I was reading the Locking document, and I tried to add a
>>>>isolation=3D"read-uncommitted" to all my class definitions in
>>>>the repository.xml file, but tha doesn't help either.
>>>>
>>>
>>>This is definitely a locking problem. OJB uses read-uncommited by
>>>default already. In the case of locking problems you would
>>>
>>get a ODMG
>>
>>>LockNotGrantedException!
>>>
>>>
>>>>How
>>>>should I declare my lockings? In the XML file, in my code
>>>>(you say the ODMG doesnt dictate a way to that).
>>>>
>>>>
>>>
>>>Locking is declared in the repository only. ODMG specifies
>>>
>>no API for
>>
>>>setting locklevels.
>>>
>>>
>>>
>>>>Please clarify this to me? Do I need to do C/S to use OJB
>>>>in a web application?
>>>>
>>>
>>>
>>>Hmm. I know of people who are using OJB in singlevm mode in
>>>
>>Web apps.
>>
>>>As long as the commit phase of ODMG transactions is
>>>
>>relatively short
>>
>>>there won't be much problems.
>>>
>>>I'm intending to have brokerpool for the singlevm mode too.
>>>
>>then it will
>>
>>> be totally safe to use the singlevm mode which is much faster !!!
>>>
>>>
>>>
>>>>Wouldn't a "OJB Helper" with a single Database instance
>>>>(singleton) be enough?
>>>>
>>>>
>>>
>>>Yes that should be sufficient.
>>>
>>>
>>>
>>>>If that's the case, how could I implement that?
>>>>
>>>
>>>Hmm, I'm not quite sure what you want to implement exactly?
>>>
>>>
>>>
>>>>Is OJB thread safe?
>>>>
>>>
>>>Yes
>>>
>>>
>>>>How can I use OJB with Tomcat + Struts?
>>>>
>>>
>>>A colleague of mine used Struts and the OJB ODMG api sucessfully.
>>>He defined special STruts actions that used ODMG
>>>
>>transactions to do the
>>
>>>persistence work. It's pretty straightforward.
>>>
>>>If you are interested I might post you sample code for this.
>>>
>>>
>>>
>>>>How can I assure that 2 transactions can READ at the same
>>>>time, without locking?
>>>>
>>>>
>>>
>>>Currently the OJB ODMG implementation relies on pessimistic locking.
>>>There is currently no optimistic locking support. (will be
>>>
>>there in 1.0)
>>
>>>But if you use "uncommitted-read" there should be no
>>>
>>locking problems.
>>
>>>You can do even more do avoid lock conflicts through WRITE
>>>
>>operations.
>>
>>>In OJB.properties you'll find an entry LockAssociations set
>>>
>>this to READ.
>>
>>>The LockAssociations entry defines the behaviour for the OJB
>>>implicit locking feature. If set to WRITE (default)
>>>
>>acquiring a write-
>>
>>>lock on a given object x implies write locks on all objects
>>>
>>associated
>>
>>>to x. If set to READ implicit read-locks are acquired.
>>>Acquiring a read-lock on x thus allways results in implicit
>>>
>>read-locks
>>
>>>on all associated objects.
>>>
>>>Using uncommited reads in combination with
>>>
>>LockAssociation=3DREAD will
>>
>>>reduce Locking related problems to a minimum.
>>>
>>>But as I said before: your problem is NOT related to locking.
>>>
>>>
>>>
>>>>Thanks in advance.
>>>>
>>>>Ricardo Arguello (an ex-Castor refugee)
>>>>
>>>
>>>I'll work hard to ensure you won't become an OJB refugee ;-)
>>>
>>>
>>>cu,
>>>
>>>Thomas
>>>
>>>
>>>
>>>_______________________________________________
>>>Objectbridge-developers mailing list
>>>Obj...@li...
>>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>>
>>>
>>
>>
>>_______________________________________________
>>Objectbridge-developers mailing list
>>Obj...@li...
>>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>>
>>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
>
>
>
|
|
From: Carl R. <ca...@db...> - 2002-02-01 17:38:18
|
> >> JDO does require implicit locking, and uses a class "enhancer" to make > >> it work. The reference implementation produces replacement java source > >> code for peristent classes, and so does not completely implement the > >> specification. > > > >to my knowledge, JDO does not mandate the use of the enhancer - so > >replacement code should be inside the spec as well. The enhancement issue > >was (and is) the subject of much debate (e.g., on TheServerSide), as you > >probably know. But of course, in order to meet the implicit locking > >requirement, there are not too many options... > > ... and they are all ugly. Hi all, in my opinion implicit locking always is awfully ugly. It may be one of the reasons for the failure of object databases to acquire a noticeable market share in the past. The loudest complaints I have read against object databases, report a nice development stage and a good running test application but dreadful fiascos, once multiple users started accessing the system. I would stay away from implicit locking, no matter what ODMG or JDO specifications suggest. Locking data during a read process is just about the worst thing you can do. We have achieved good results on relational systems in the past, by using a combination of semaphores and fine-tuned *manually coded* row locks. ...my 2 cents. Kind regards, Carl --- Carl Rosenberger db4o - database for objects - http://www.db4o.com |
|
From: Doug C. <de...@fl...> - 2002-02-01 17:03:34
|
>> BTW, I am not advocating changing ojb to correct this problem, but >> implicit locking should not be communicated to users as a feature, >> and claims about compliance should be made with caveats. > >some of this does sound like OJB needs to be modified, doesn't it? Well, if you want ODMG compliance, yes. We might also consider read locking the results of queries. But the hair required to fix this completely is so enormous that I think it would completely change the nature of ojb. I am content with explicitly locking objects before accessing or modifying them. >> /*5*/ transaction 2 aborts. This is irrelevant. >> > >does not look that irrelevant to me. Modifications done in transaction 2 >should be rolled back in the instance as well, and thus not be visible >afterwards. These modifications would be rolled back if transaction 2 had obtained a write lock. At least I believe that's the design, I haven't tested it. So the bug is not getting the write lock. >Visibility while the transaction is still active should depend >on the isolation level of the other transaction (i.e., UNCOMMITTED READ >should see it, COMMITTED READ shouldn't). Yes. I tested it both ways: same result. >> JDO does require implicit locking, and uses a class "enhancer" to make >> it work. The reference implementation produces replacement java source >> code for peristent classes, and so does not completely implement the >> specification. > >to my knowledge, JDO does not mandate the use of the enhancer - so >replacement code should be inside the spec as well. The enhancement issue >was (and is) the subject of much debate (e.g., on TheServerSide), as you >probably know. But of course, in order to meet the implicit locking >requirement, there are not too many options... ... and they are all ugly. e |
|
From: Doug C. <de...@fl...> - 2002-02-01 07:41:20
|
Based on my experience with object databases, it surprises me that ojb
can be considered "fully ODMG 3.0 compliant." I must admit that I do
not have a copy of the ODMG 3.0 spec at hand (is there a freely
downloadable copy on the web?). I do have the JDO spec, though, and
this same issue will certainly need to be addressed before a JDO
compliant implementation can be completed, so I am reporting it here.
The problem is: implicit locking doesn't work.
BTW, I am not advocating changing ojb to correct this problem, but
implicit locking should not be communicated to users as a feature, and
claims about compliance should be made with caveats.
Consider the following comments from interface org.odmg.Transaction:
* Read locks are implicitly obtained on objects as they are accessed.
* Write locks are implicitly obtained as objects are modified.
Here is a sequence of events to demonstrate that the implicit locking
is not taking place (also see the junit test below where the number
comments from this sequence are duplicated):
/*1*/ transaction 1 obtains an object A1 using OQLQuery
/*2*/ transaction 1 accesses A1 by reading a field with an accessor
NOTE: A1 is not locked at this point as reported by LockMap.hasReadLock
This is the first bug; I worked around it by calling lock explicitly.
/*3*/ transaction 2 obtains an object A2 using OQLQuery (A1 == A2)
/*4*/ transaction 2 modifies A2 by writing a field with a setter
NOTE: A2 is not write-locked at this point, otherwise
the transaction would be stopped and the write prevented
This is the second bug.
/*5*/ transaction 2 aborts. This is irrelevant.
/*6*/ transaction 1 accesses A1 by reading the same field as in /*2*/
NOTE: the value has changed despite the read-lock.
This is a consequence of the second bug.
If transaction 1 were allowed to proceed, (a) the object A1 will look
dirty despite the fact that transaction 1 didn't write it, and (b)
transaction 1 could read bad data from an aborted transaction. Data are
corrupted, and transaction isolation is violated.
The moral of the story is that ojb does not support implicit locks
correctly. A user must use explicit locking for reads and writes
before accessing or modifying an object, respectively.
Most ODMG Java implementations do implicit locking by either:
- using a custom JVM
and requiring persistent classes to be registered
and/or..
- modifying persistent classes'
source code or .class files to intercept accesses
and making all persistent fields private
In order to support "transparent persistence" AND implicit locking it
would be necessary to modify any class which accesses a persistent
class's fields.
JDO does require implicit locking, and uses a class "enhancer" to make
it work. The reference implementation produces replacement java source
code for peristent classes, and so does not completely implement the
specification. A better approach would be to implement a custom class
loader to "enhance" the persistent classes at load time.
Regards,
e
/* -=- junit test for test/odmg/OdmgExamples.java -=- */
/* e added read/write thread for testThreadedRWR */
class OtherThread extends Thread
{
Implementation odmg;
OtherThread(Implementation odmg)
{
this.odmg = odmg;
}
public void run()
{
Transaction tx2 = odmg.newTransaction();
try
{
tx2.begin();
OQLQuery query = odmg.newOQLQuery();
query.create("select anArticle from " + Article.class.getName() + " where articleId = 60");
/*3*/ List results = (List) query.execute();
Article a2 = (Article) results.get(0);
/*4*/ a2.addToStock(23); // --- the "implicit" write lock
/*5*/ tx2.abort();
}
catch (Exception ex)
{
tx2.abort();
fail("ODMGException: " + ex.getMessage());
}
}
}
public void testThreadedRWR()
{
// get facade instance
Implementation odmg = OJB.getInstance();
Database db = odmg.newDatabase();
//open database
try
{
db.open(databaseName, Database.OPEN_READ_WRITE);
}
catch (ODMGException ex)
{
fail("ODMGException: " + ex.getMessage());
}
Transaction tx1 = odmg.newTransaction();
OtherThread o = new OtherThread( odmg );
try
{
tx1.begin();
OQLQuery query = odmg.newOQLQuery();
query.create("select anArticle from " + Article.class.getName() + " where articleId = 60");
/*1*/ List results = (List) query.execute();
Article a1 = (Article) results.get(0);
/*2*/ int a1s1 = a1.getStock(); // --- the implicit read lock
if( ! ojb.odmg.locking.LockMapFactory.getLockMap().hasReadLock(
(ojb.odmg.TransactionImpl )tx1, a1) )
{
OJB.getLogger().error( "!!! not read locked !!!" );
//fail( "OQLQuery.execute didn't real-lock the result" );
tx1.lock( a1, Transaction.READ );
}
o.start(); // run the other RW transaction
o.join(); // wait for it to finish
/*6*/ int a1s2 = a1.getStock();
if( a1s1 != a1s2 )
{
OJB.getLogger().error( "!!! dirty cache !!!" );
fail( "touching didn't write-lock" );
}
tx1.abort();
}
catch (Exception ex)
{
tx1.abort();
fail("ODMGException: " + ex.getMessage());
}
// close database
try
{
db.close();
}
catch (ODMGException ex)
{
fail("ODMGException: " + ex.getMessage());
}
}
/* */
|
|
From: <ri...@ya...> - 2002-01-31 17:19:43
|
Hello all, How do i correctly delete an element from a Collection? If I have a parent, who has children, do I have to load the parent = first, remove the child from the parent's java Collection, and then = persist the parent? Can somebody send me some example code, please? Thanks in advance. Ricardo Arguello |
9 messages has been excluded from this view by a project administrator.
