Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO] [0.8.0]
|
| Re: [CDO] [0.8.0] [message #94066 is a reply to message #94032] |
Fri, 24 August 2007 14:09   |
Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Hi Simon,
Originally I planned to rework the various caches a bit later. But since
the IStore API seems to approach a pretty stable state we could consider
to optimize some non-functional aspects now.
I've already had a look into EHCache and some of its competitors and I
must admit that I was a bit disappointed that they are so simple. If I
remember correctly they only use separate files in a folder to store
objects.
Do you know how the various frameworks including JCS relate to each
other? Are there integrations between them?
In the end I think it'd be good if the caching provider could be
flexibly contributed.
I suggest that you send me your patches with JCS support and I review
them carefully.
Maybe I'm able to factor out the underlying caching system and make it
configurable.
An Apache license is a good starting position but I'm not allowed to
commit any third party (non-EPL) code prior to an official IP approval.
But don't worry, I'll manage that.
BTW. the work you've done on the OODB store implementation for CDO, will
you be able and willing to contribute it or is it protected by
copyrights of your employer?
Cheers
/Eike
Simon McDuff schrieb:
> hi Eike,
>
> We are deploying a version of your framework next week to our developper so
> they can start to use it.
> The only show stopper we have it is the management of memory. We always goes
> in a OUTOFMemoryException. Do you mind if I integrate JCS in the CDO
> Project?
>
> http://jakarta.apache.org/jcs/
>
> It is an open source project. I plan to put it in the client and server
> side.
> I will need also to add a new Store, IStoreReader, IStoreWriter to keep
> objects in memory for the testcase that we do not use any Store. Why ??
> Since the repository will not necessary have all the objects in its
> cache...We need a place to keep them. Make sense?
>
> What do you think.. do you mind ?
> If you agree.. how do you like to proceed ? I can send you all the file in
> patches so you can revised them.
> Or do you prefer that I keep modifications in my side ?
> Or any suggestions ?
>
>
> Simon
>
>
>
|
|
| |
| Re: [CDO] [0.8.0] [message #94108 is a reply to message #94094] |
Fri, 24 August 2007 14:53 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Simon McDuff schrieb:
> JCS compare their products with EHCache
> http://jakarta.apache.org/jcs/JCSvsEHCache.html
>
I'll read it...
> You are right EHCache is very disappointed.
> JCS is very very powerful caching.. you can sotre on the disk.. but I will
> put the default to be only in memory.
>
> For the In-Memory implementation of the Store I will use JCS as well... but
> I will create object on the disk....
>
That doesn't make sense to me but maybe I don't understand what you mean ;-)
> JCS have also the capability to define region...
> Its region have their cache strategy..
> A region could be a EPackage or a EClass!!! So the user will have the
> control of their retentition like they want.
>
Sounds good.
When you're ready with your patch please attach it to an enhancement
request in Bugzilla.
Cheers
/Eike
|
|
| |
| Re: [CDO] [0.8.0] [message #94136 is a reply to message #94122] |
Fri, 24 August 2007 15:18 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------000504090509060701050308
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
>>> For the In-Memory implementation of the Store I will use JCS as well...
>>> but I will create object on the disk....
>>>
>>>
>> That doesn't make sense to me but maybe I don't understand what you mean
>> ;-)
>>
>
> In you test case right now, when you create objects we assume that the
> server cache will keep objects after different transaction.
> But by adding JCS cache on the server and the client ... this isn't true
> anymore.
> It is possible that after creating objects and committed them... The server
> cache will discard some objects.
> When the other transaction will try to fetch an object... it will failed
> since the server cache will not have them anymore.
>
> By adding a In-Memory implementation.... It will assure that discarded
> objects are still available.
>
I see. I was a bit confused since for a complete in-memory
implementation of the server (aka RevisionManager) you only need to turn
off disk caching (when you have implemented it) and use a NOOPStore
(which I removed recently).
If I got you right you want to implement IStore backed by a disk based
JCS cache?
Cheers
/Eike
--------------000504090509060701050308
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:famrrg$ldq$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">For the In-Memory implementation of the Store I will use JCS as well...
but I will create object on the disk....
</pre>
</blockquote>
<pre wrap="">That doesn't make sense to me but maybe I don't understand what you mean
;-)
</pre>
</blockquote>
<pre wrap=""><!---->
In you test case right now, when you create objects we assume that the
server cache will keep objects after different transaction.
But by adding JCS cache on the server and the client ... this isn't true
anymore.
It is possible that after creating objects and committed them... The server
cache will discard some objects.
When the other transaction will try to fetch an object... it will failed
since the server cache will not have them anymore.
By adding a In-Memory implementation.... It will assure that discarded
objects are still available.
</pre>
</blockquote>
I see. I was a bit confused since for a
|
|
|
| Re: [CDO] [0.8.0] [message #94243 is a reply to message #94066] |
Sun, 26 August 2007 15:36 |
 Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_00D6_01C7E7D5.5A22AA20
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
Hi Eike,
I started the implementation of the JCS.
I expect to change the following maps
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions;
CDOViewImpl
private Map<CDOID, InternalCDOObject> objects;
I didn`t all complete it.. but let me know if you see a problem with =
that.
We have 3 contexts where caching is used.
Server side :
RevisionManager
Client side
CDOViewImpl
CDORevisionManagerImpl=20
I think only one of them should be using a factory pattern : =
RevisionManager. Because this is where people would like to have control =
because it is on the server side that it could be very slow. Let say =
when you deploy you could have many CDOServer and your caching =
strategy.. is sharing cache between all CDOServer.
I planned to use IManagedContainer to achieve that.
For the client side, we shouldn`t use factory.. but define an interface =
for parameters that we support
interface CDOCache
{
setMaxObjects()
getMaxObjects();
dropObjectCache();
isObjectCache();
}
CDOViewImpl and CDORevisionManagerImpl will implement them using JCS.
Let me know want you think ?
Do you think we should put flexibility to change the implementation in =
the client side as well ?
"Eike Stepper" <stepper@sympedia.de> a =E9crit dans le message de news: =
famopr$9pe$1@build.eclipse.org...
> Hi Simon,
>=20
> Originally I planned to rework the various caches a bit later. But =
since=20
> the IStore API seems to approach a pretty stable state we could =
consider=20
> to optimize some non-functional aspects now.
> I've already had a look into EHCache and some of its competitors and I =
> must admit that I was a bit disappointed that they are so simple. If I =
> remember correctly they only use separate files in a folder to store=20
> objects.
> Do you know how the various frameworks including JCS relate to each=20
> other? Are there integrations between them?
>=20
> In the end I think it'd be good if the caching provider could be=20
> flexibly contributed.
> I suggest that you send me your patches with JCS support and I review=20
> them carefully.
> Maybe I'm able to factor out the underlying caching system and make it =
> configurable.
>=20
> An Apache license is a good starting position but I'm not allowed to=20
> commit any third party (non-EPL) code prior to an official IP =
approval.
> But don't worry, I'll manage that.
>=20
> BTW. the work you've done on the OODB store implementation for CDO, =
will=20
> you be able and willing to contribute it or is it protected by=20
> copyrights of your employer?
>=20
> Cheers
> /Eike
>=20
>=20
> Simon McDuff schrieb:
>> hi Eike,
>>
>> We are deploying a version of your framework next week to our =
developper so=20
>> they can start to use it.
>> The only show stopper we have it is the management of memory. We =
always goes=20
>> in a OUTOFMemoryException. Do you mind if I integrate JCS in the CDO=20
>> Project?
>>
>> http://jakarta.apache.org/jcs/
>>
>> It is an open source project. I plan to put it in the client and =
server=20
>> side.
>> I will need also to add a new Store, IStoreReader, IStoreWriter to =
keep=20
>> objects in memory for the testcase that we do not use any Store. Why =
??=20
>> Since the repository will not necessary have all the objects in its=20
>> cache...We need a place to keep them. Make sense?
>>
>> What do you think.. do you mind ?
>> If you agree.. how do you like to proceed ? I can send you all the =
file in=20
>> patches so you can revised them.
>> Or do you prefer that I keep modifications in my side ?
>> Or any suggestions ?
>>
>>
>> Simon
>>
>>
>>
------=_NextPart_000_00D6_01C7E7D5.5A22AA20
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-15">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Eike,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I started the implementation of the=20
JCS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expect to change the following =
maps</FONT></DIV>
<DIV><U><FONT color=3D#0000ff size=3D2>
<P>CDORevisionResolverImpl</P></U></FONT></DIV>
<DIV><FONT size=3D2><B><FONT color=3D#7f0055 size=3D2>
<P>private</B></FONT><FONT size=3D2> Map<CDOID, TimeLine> =
</FONT><FONT=20
color=3D#0000c0 size=3D2>revisions</FONT><FONT size=3D2>;<FONT =
size=3D2></P>
<P>CDOViewImpl</P></FONT></FONT><FONT color=3D#0000c0 size=3D2><FONT =
size=3D2>
<P></FONT></FONT></FONT><FONT face=3DArial size=3D2><B><FONT =
color=3D#7f0055=20
size=3D2>private</B></FONT><FONT size=3D2> Map<CDOID, =
InternalCDOObject>=20
</FONT><FONT color=3D#0000c0 size=3D2>objects;</FONT></FONT><FONT =
face=3DArial=20
size=3D2></FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn`t all complete it.. but let me =
know if you=20
see a problem with that.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We have 3 contexts where caching is=20
used.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Server side :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RevisionManager</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Client side</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDORevisionManagerImpl </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think only one of them should be =
using a factory=20
pattern : RevisionManager. Because this is where people would like to =
have=20
control because it is on the server side that it could be very =
slow. Let=20
say when you deploy you could have many CDOServer and your caching =
strategy.. is=20
sharing cache between all CDOServer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I planned to use IManagedContainer to =
achieve=20
that.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>For the client side, we shouldn`t use =
factory.. but=20
define an interface for parameters that we support</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>interface CDOCache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
setMaxObjects()</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
getMaxObjects();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
dropObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
isObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT> and=20
CDORevisionManagerImpl will implement them using JCS.</DIV>
<DIV></FONT> </DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Let me know want you think =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you think we should put flexibility =
to change=20
the implementation in the client side as well ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"Eike Stepper" <</FONT><A=20
href=3D"mailto:stepper@sympedia.de"><FONT face=3DArial=20
size=3D2>stepper@sympedia.de</FONT></A><FONT face=3DArial size=3D2>> =
a =E9crit dans=20
le message de news: </FONT><A =
href=3D"mailto:famopr$9pe$1@build.eclipse.org"><FONT=20
face=3DArial size=3D2>famopr$9pe$1@build.eclipse.org</FONT></A><FONT =
face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> Hi =
Simon,<BR>> <BR>>=20
Originally I planned to rework the various caches a bit later. But since =
<BR>> the IStore API seems to approach a pretty stable state we could =
consider <BR>> to optimize some non-functional aspects now.<BR>> =
I've=20
already had a look into EHCache and some of its competitors and I =
<BR>> must=20
admit that I was a bit disappointed that they are so simple. If I =
<BR>>=20
remember correctly they only use separate files in a folder to store =
<BR>>=20
objects.<BR>> Do you know how the various frameworks including JCS =
relate to=20
each <BR>> other? Are there integrations between them?<BR>> =
<BR>> In=20
the end I think it'd be good if the caching provider could be <BR>> =
flexibly=20
contributed.<BR>> I suggest that you send me your patches with JCS =
support=20
and I review <BR>> them carefully.<BR>> Maybe I'm able to factor =
out the=20
underlying caching system and make it <BR>> configurable.<BR>> =
<BR>> An=20
Apache license is a good starting position but I'm not allowed to =
<BR>>=20
commit any third party (non-EPL) code prior to an official IP =
approval.<BR>>=20
But don't worry, I'll manage that.<BR>> <BR>> BTW. the work you've =
done on=20
the OODB store implementation for CDO, will <BR>> you be able and =
willing to=20
contribute it or is it protected by <BR>> copyrights of your=20
employer?<BR>> <BR>> Cheers<BR>> /Eike<BR>> <BR>> =
<BR>> Simon=20
McDuff schrieb:<BR>>> hi Eike,<BR>>><BR>>> =
We are=20
deploying a version of your framework next week to our developper so=20
<BR>>> they can start to use it.<BR>>> The only show stopper =
we have=20
it is the management of memory. We always goes <BR>>> in a=20
OUTOFMemoryException. Do you mind if I integrate JCS in the CDO =
<BR>>>=20
Project?<BR>>><BR>>> </FONT><A=20
href=3D"http://jakarta.apache.org/jcs/"><FONT face=3DArial=20
size=3D2>http://jakarta.apache.org/jcs/</FONT></A><BR><FONT face=3DArial =
size=3D2>>><BR>>> It is an open source project. I plan to =
put it in=20
the client and server <BR>>> side.<BR>>> I will need also to =
add a=20
new Store, IStoreReader, IStoreWriter to keep <BR>>> objects in =
memory for=20
the testcase that we do not use any Store. Why ?? <BR>>> Since the =
repository will not necessary have all the objects in its <BR>>>=20
cache...We need a place to keep them. Make =
sense?<BR>>><BR>>> What=20
do you think.. do you mind ?<BR>>> If you agree.. how do you like =
to=20
proceed ? I can send you all the file in <BR>>> patches so you can =
revised=20
them.<BR>>> Or do you prefer that I keep modifications in my side=20
?<BR>>> Or any suggestions ?<BR>>><BR>>><BR>>>=20
Simon<BR>>><BR>>><BR>>> </FONT></BODY></HTML>
------=_NextPart_000_00D6_01C7E7D5.5A22AA20--
|
|
|
| Re: [CDO] [0.8.0] [message #94272 is a reply to message #94243] |
Mon, 27 August 2007 15:05 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------050802030508060208090707
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Simon,
See my comments inline...
Simon McDuff schrieb:
> Hi Eike,
>
> I started the implementation of the JCS.
> I expect to change the following maps
> _ _
>
> _CDORevisionResolverImpl_
>
> * *
>
> *private* Map<CDOID, TimeLine> revisions;
>
> CDOViewImpl
>
> *private* Map<CDOID, InternalCDOObject> objects;
>
>
> I didn`t all complete it.. but let me know if you see a problem with that.
>
> We have 3 contexts where caching is used.
>
> Server side :
> RevisionManager
>
> Client side
> CDOViewImpl
> CDORevisionManagerImpl
I'd start with RevisionManager and CDORevisionManagerImpl because they
hold big objects (revisions).
You'll notice that a revision manager does not directly hold the
revisions. Instead it holds TimeLine objects which in turn hold the
revisions.
> I think only one of them should be using a factory pattern :
> RevisionManager. Because this is where people would like to have
> control because it is on the server side that it could be very slow.
> Let say when you deploy you could have many CDOServer and your caching
> strategy.. is sharing cache between all CDOServer.
Maybe I don't fully understand the details of JCS (what exactly is a
"cache") but I can't imagine a rwason why we would want to share caches
between CDO servers.
Even cache sharing between the different repositories of a CDO server
doesn't seem a good idea.
> I planned to use IManagedContainer to achieve that.
That's generally a good idea ;-)
> For the client side, we shouldn`t use factory.. but define an
> interface for parameters that we support
>
> interface CDOCache
> {
> setMaxObjects()
> getMaxObjects();
> dropObjectCache();
> isObjectCache();
> }
Is it possible to move the caching infrastructure from cdo.xyz to
net4j.util?
It would be easier to reuse and it doesn't seem / shouldn't be dependent
on CDO.
>
> CDOViewImpl and CDORevisionManagerImpl will implement them using JCS.
>
> Let me know want you think ?
> Do you think we should put flexibility to change the implementation in
> the client side as well ?
In the end, yes.
But this is not urgent ;-)
Looking forwar to see what you'll develop!
Cheers
/Eike
--------------050802030508060208090707
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Simon,<br>
<br>
See my comments inline...<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:fas6m2$km1$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Hi Eike,</font></div>
<div>
|
|
|
| Re: [CDO] [0.8.0] [message #94274 is a reply to message #94272] |
Tue, 28 August 2007 00:13 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_01BC_01C7E8E6.C544EFE0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
"Eike Stepper" <stepper@sympedia.de> a =E9crit dans le message de =
news: faup74$frt$4@build.eclipse.org...
Hi Simon,
See my comments inline...
Simon McDuff schrieb:=20
Hi Eike,
I started the implementation of the JCS.
I expect to change the following maps
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions;
CDOViewImpl
private Map<CDOID, InternalCDOObject> objects;
I didn`t all complete it.. but let me know if you see a problem with =
that.
We have 3 contexts where caching is used.
Server side :
RevisionManager
Client side
CDOViewImpl
CDORevisionManagerImpl
I'd start with RevisionManager and CDORevisionManagerImpl because they =
hold big objects (revisions).
You'll notice that a revision manager does not directly hold the =
revisions. Instead it holds TimeLine objects which in turn hold the =
revisions.
I think only one of them should be using a factory pattern : =
RevisionManager. Because this is where people would like to have control =
because it is on the server side that it could be very slow. Let say =
when you deploy you could have many CDOServer and your caching =
strategy.. is sharing cache between all CDOServer.
Maybe I don't fully understand the details of JCS (what exactly is a =
"cache") but I can't imagine a rwason why we would want to share caches =
between CDO servers.
Even cache sharing between the different repositories of a CDO server =
doesn't seem a good idea.
I planned to use IManagedContainer to achieve that.
That's generally a good idea ;-)
For the client side, we shouldn`t use factory.. but define an =
interface for parameters that we support
interface CDOCache
{
setMaxObjects()
getMaxObjects();
dropObjectCache();
isObjectCache();
}
Is it possible to move the caching infrastructure from cdo.xyz to =
net4j.util?
It would be easier to reuse and it doesn't seem / shouldn't be =
dependent on CDO.
CDOViewImpl and CDORevisionManagerImpl will implement them using =
JCS.
Let me know want you think ?
Do you think we should put flexibility to change the implementation =
in the client side as well ?
In the end, yes.
But this is not urgent ;-)
Looking forwar to see what you'll develop!
Cheers
/Eike
------=_NextPart_000_01BC_01C7E8E6.C544EFE0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> a =
=E9crit dans le=20
message de news: <A=20
=
href=3D"mailto:faup74$frt$4@build.eclipse.org">faup74$frt$4@build.eclipse=
..org</A>...</DIV>Hi=20
Simon,<BR><BR>See my comments inline...<BR><BR><BR>Simon McDuff =
schrieb:=20
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>Hi Eike,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I started the implementation of the =
JCS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expect to change the following=20
maps</FONT></DIV>
<DIV><U><FONT color=3D#0000ff size=3D2></FONT></U>
<P><U><FONT color=3D#0000ff=20
size=3D2>CDORevisionResolverImpl</FONT></U></P></DIV>
<DIV><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2></FONT></B></FONT>
<P><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2>private</FONT></B><FONT=20
size=3D2> Map<CDOID, TimeLine> </FONT><FONT color=3D#0000c0=20
size=3D2>revisions</FONT><FONT size=3D2>;</FONT></FONT></P>
<P><FONT size=3D2><FONT size=3D2><FONT=20
size=3D2>CDOViewImpl</FONT></FONT></FONT></P><FONT size=3D2><FONT =
color=3D#0000c0=20
size=3D2><FONT size=3D2></FONT></FONT></FONT>
<P><FONT face=3DArial size=3D2><B><FONT color=3D#7f0055=20
size=3D2>private</FONT></B><FONT size=3D2> Map<CDOID, =
InternalCDOObject>=20
</FONT><FONT color=3D#0000c0 =
size=3D2>objects;</FONT></FONT></P></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn`t all complete it.. but let =
me know if=20
you see a problem with that.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>We have 3 contexts where caching is =
used.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Server side :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RevisionManager</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Client side</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>CDORevisionManagerImpl</FONT></DIV></BLOCKQUOTE ><BR>I'd start =
with=20
RevisionManager and <FONT face=3DArial size=3D2>CDORevisionManagerImpl =
because=20
they hold big objects (revisions).<BR>You'll notice that a revision =
manager=20
does not directly hold the revisions. Instead it holds TimeLine =
objects which=20
in turn hold the revisions.<BR><BR></FONT>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2></FONT></DIV>
<DIV> <FONT face=3DArial size=3D2>I think only one of them =
should be using=20
a factory pattern : RevisionManager. Because this is where people =
would like=20
to have control because it is on the server side that it could =
be very=20
slow. Let say when you deploy you could have many CDOServer and your =
caching=20
strategy.. is sharing cache between all =
CDOServer.</FONT></DIV></BLOCKQUOTE>
<DIV>Maybe I don't fully understand the details of JCS (what exactly =
is a=20
"cache") but I can't imagine a rwason why we would want to share =
caches=20
between CDO servers.<BR>Even cache sharing between the different =
repositories=20
of a CDO server doesn't seem a good idea.<BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><BR> </DIV>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>I planned to use IManagedContainer =
to achieve=20
that.</FONT></DIV></BLOCKQUOTE>That's generally a good idea =
;-)<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>For the client side, we shouldn`t =
use factory..=20
but define an interface for parameters that we support</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>interface CDOCache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
setMaxObjects()</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
getMaxObjects();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
dropObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
isObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV></BLOCKQUOTE>Is it =
possible to move=20
the caching infrastructure from cdo.xyz to net4j.util?<BR>It would be =
easier=20
to reuse and it doesn't seem / shouldn't be dependent on CDO.<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2>CDOViewImpl</FONT> and =
CDORevisionManagerImpl will=20
implement them using JCS.</FONT></DIV>
<DIV> </DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Let me know want you think =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you think we should put =
flexibility to=20
change the implementation in the client side as well=20
?</FONT></DIV></BLOCKQUOTE>In the end, yes.<BR>But this is not urgent=20
;-)<BR><BR>Looking forwar to see what you'll=20
develop!<BR><BR>Cheers<BR>/Eike<BR><BR></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_01BC_01C7E8E6.C544EFE0--
|
|
|
| Re: [CDO] [0.8.0] [message #94275 is a reply to message #94272] |
Tue, 28 August 2007 00:27 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_01D2_01C7E8E8.A0AF2CC0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
Right now, in the framework We have one instance of IManagedContainer =
that configure everything.
The problem with that is to be able to create a different strategy to =
every Repository.. I will need one for each Repository... right ?
Do you still want to have only one instance in the system or we can have =
more ?
It will change my strategy... but if we can have more...
Repository would extends ManagedContainer.
So every objects that Repository owns would be able to get a custom =
factory for any attributs in the future.
Also CDOSessionImpl will have as well a ManagedContainer (by =
composition) to take care of the CDOViewIMpl...and the=20
CDORevisionManagerImpl.
By Default I will put the HashMap... or the JCS.. which ever you prefer.
[Eike] Is it possible to move the caching infrastructure from cdo.xyz to =
net4j.util?
[Eike] It would be easier to reuse and it doesn't seem / shouldn't be =
dependent on CDO.
I agree that it shouldn't be dependant of CDO... but =CCt should'nt be =
dependant of Net4J as well :-) Right ?
I will put it under net4j.util.
"Eike Stepper" <stepper@sympedia.de> a =E9crit dans le message de =
news: faup74$frt$4@build.eclipse.org...
Hi Simon,
See my comments inline...
Simon McDuff schrieb:=20
Hi Eike,
I started the implementation of the JCS.
I expect to change the following maps
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions;
CDOViewImpl
private Map<CDOID, InternalCDOObject> objects;
I didn`t all complete it.. but let me know if you see a problem with =
that.
We have 3 contexts where caching is used.
Server side :
RevisionManager
Client side
CDOViewImpl
CDORevisionManagerImpl
I'd start with RevisionManager and CDORevisionManagerImpl because they =
hold big objects (revisions).
You'll notice that a revision manager does not directly hold the =
revisions. Instead it holds TimeLine objects which in turn hold the =
revisions.
I think only one of them should be using a factory pattern : =
RevisionManager. Because this is where people would like to have control =
because it is on the server side that it could be very slow. Let say =
when you deploy you could have many CDOServer and your caching =
strategy.. is sharing cache between all CDOServer.
Maybe I don't fully understand the details of JCS (what exactly is a =
"cache") but I can't imagine a rwason why we would want to share caches =
between CDO servers.
Even cache sharing between the different repositories of a CDO server =
doesn't seem a good idea.
I planned to use IManagedContainer to achieve that.
That's generally a good idea ;-)
For the client side, we shouldn`t use factory.. but define an =
interface for parameters that we support
interface CDOCache
{
setMaxObjects()
getMaxObjects();
dropObjectCache();
isObjectCache();
}
Is it possible to move the caching infrastructure from cdo.xyz to =
net4j.util?
It would be easier to reuse and it doesn't seem / shouldn't be =
dependent on CDO.
CDOViewImpl and CDORevisionManagerImpl will implement them using =
JCS.
Let me know want you think ?
Do you think we should put flexibility to change the implementation =
in the client side as well ?
In the end, yes.
But this is not urgent ;-)
Looking forwar to see what you'll develop!
Cheers
/Eike
------=_NextPart_000_01D2_01C7E8E8.A0AF2CC0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Right now, in the framework We have one =
instance of=20
IManagedContainer that configure everything.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The problem with that is to be able to =
create a=20
different strategy to every Repository.. I will need one for each =
Repository...=20
right ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Do you still want to have only one =
instance in=20
the system or we can have more ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It will change my strategy... but if we =
can have=20
more...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>Repository </FONT>would =
extends=20
ManagedContainer.</DIV>
<DIV>
<P>So every objects that Repository owns would be able to get a=20
custom factory for any attributs in the future.</P>
<P>Also CDOSessionImpl will have as well a ManagedContainer (by =
composition)=20
to take care of the CDOViewIMpl...and the <FONT size=3D2></P>
<P>CDORevisionManagerImpl.</P>
<P>By Default I will put the HashMap... or the JCS.. which ever you =
prefer.</P>
<P>[Eike] Is it possible to move the caching infrastructure from cdo.xyz =
to=20
net4j.util?<BR>[Eike] It would be easier to reuse and it doesn't seem /=20
shouldn't be dependent on CDO.</P>
<P>I agree that it shouldn't be dependant of CDO... but =CCt should'nt =
be=20
dependant of Net4J as well :-) Right ?</P>
<P>I will put it under net4j.util.</P>
<P> </P>
<P></FONT> </P>
<P></FONT> </P></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> a =
=E9crit dans le=20
message de news: <A=20
=
href=3D"mailto:faup74$frt$4@build.eclipse.org">faup74$frt$4@build.eclipse=
..org</A>...</DIV>Hi=20
Simon,<BR><BR>See my comments inline...<BR><BR><BR>Simon McDuff =
schrieb:=20
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>Hi Eike,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I started the implementation of the =
JCS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expect to change the following=20
maps</FONT></DIV>
<DIV><U><FONT color=3D#0000ff size=3D2></FONT></U>
<P><U><FONT color=3D#0000ff=20
size=3D2>CDORevisionResolverImpl</FONT></U></P></DIV>
<DIV><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2></FONT></B></FONT>
<P><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2>private</FONT></B><FONT=20
size=3D2> Map<CDOID, TimeLine> </FONT><FONT color=3D#0000c0=20
size=3D2>revisions</FONT><FONT size=3D2>;</FONT></FONT></P>
<P><FONT size=3D2><FONT size=3D2><FONT=20
size=3D2>CDOViewImpl</FONT></FONT></FONT></P><FONT size=3D2><FONT =
color=3D#0000c0=20
size=3D2><FONT size=3D2></FONT></FONT></FONT>
<P><FONT face=3DArial size=3D2><B><FONT color=3D#7f0055=20
size=3D2>private</FONT></B><FONT size=3D2> Map<CDOID, =
InternalCDOObject>=20
</FONT><FONT color=3D#0000c0 =
size=3D2>objects;</FONT></FONT></P></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn`t all complete it.. but let =
me know if=20
you see a problem with that.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>We have 3 contexts where caching is =
used.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Server side :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RevisionManager</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Client side</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>CDORevisionManagerImpl</FONT></DIV></BLOCKQUOTE ><BR>I'd start =
with=20
RevisionManager and <FONT face=3DArial size=3D2>CDORevisionManagerImpl =
because=20
they hold big objects (revisions).<BR>You'll notice that a revision =
manager=20
does not directly hold the revisions. Instead it holds TimeLine =
objects which=20
in turn hold the revisions.<BR><BR></FONT>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2></FONT></DIV>
<DIV> <FONT face=3DArial size=3D2>I think only one of them =
should be using=20
a factory pattern : RevisionManager. Because this is where people =
would like=20
to have control because it is on the server side that it could =
be very=20
slow. Let say when you deploy you could have many CDOServer and your =
caching=20
strategy.. is sharing cache between all =
CDOServer.</FONT></DIV></BLOCKQUOTE>
<DIV>Maybe I don't fully understand the details of JCS (what exactly =
is a=20
"cache") but I can't imagine a rwason why we would want to share =
caches=20
between CDO servers.<BR>Even cache sharing between the different =
repositories=20
of a CDO server doesn't seem a good idea.<BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I planned to use IManagedContainer to =
achieve=20
that.</FONT></DIV>That's generally a good idea ;-)<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>For the client side, we shouldn`t =
use factory..=20
but define an interface for parameters that we support</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>interface CDOCache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
setMaxObjects()</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
getMaxObjects();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
dropObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
isObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV></BLOCKQUOTE>Is it =
possible to move=20
the caching infrastructure from cdo.xyz to net4j.util?<BR>It would be =
easier=20
to reuse and it doesn't seem / shouldn't be dependent on CDO.<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2>CDOViewImpl</FONT> and =
CDORevisionManagerImpl will=20
implement them using JCS.</FONT></DIV>
<DIV> </DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Let me know want you think =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you think we should put =
flexibility to=20
change the implementation in the client side as well=20
?</FONT></DIV></BLOCKQUOTE>In the end, yes.<BR>But this is not urgent=20
;-)<BR><BR>Looking forwar to see what you'll=20
develop!<BR><BR>Cheers<BR>/Eike<BR><BR></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_01D2_01C7E8E8.A0AF2CC0--
|
|
|
| Re: [CDO] [0.8.0] [message #94277 is a reply to message #94275] |
Tue, 28 August 2007 05:15 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------080402090409020309020409
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Simon McDuff schrieb:
> Right now, in the framework We have one instance of IManagedContainer
> that configure everything.
>
> The problem with that is to be able to create a different strategy to
> every Repository.. I will need one for each Repository... right ?
Yes, that seems reasonable.
> Do you still want to have only one instance in the system or we can
> have more ?
Do you mean one instance of a repository per server?
Then no, there can be arbitrary numbers of repositories in the server
container.
They are created by the RepositoryConfigurator on server startup.
We would have to add config elements for the cache configuration...
> It will change my strategy... but if we can have more...
>
>
> Repository would extends ManagedContainer.
Repository already extends IContainer: public interface IRepository
extends IContainer<IRepositoryElement>
Do you really mean it should extend IManagedContainer?
> So every objects that Repository owns would be able to get a
> custom factory for any attributs in the future.
>
Could you explain a bit what you mean with that?
Which objects, which attributes?
I generally try to avoid components having dependencies on the wiring
framework (IManagedContainer).
But I must dmit that in some cases it would be easier with such a
dependency. For example IConnector needs a way to create configurable
protocols.
At the moment I pass in a FactoryRegistry and a PostProcessors list.
Originally it was only a FactoryRegistry which does not depend on
IManageContainer.
But now that IElementProcessor is needed to configure IStreamWrappers I
already have a dependency on IManagedContainer.
There are 3 resolutions:
1. Remove the IManagedContainer dependency from IElementProcessor (Not
sure if that is good).
2. Replace FactoryRegistry and IElementProcessor by a full
IManagedContainer reference.
3. Replace FactoryRegistry and IElementProcessor by a IProtocolProvider
reference and have an implementation of this interface that uses an
IManagedContainer.
I generally prefer the 3rd option at the moment since it gives full
power of an IManagedContainer without having IConnector depend on
IManagedContainer.
> Also CDOSessionImpl will have as well a ManagedContainer (by
> composition) to take care of the CDOViewIMpl...and the
>
> CDORevisionManagerImpl.
>
> By Default I will put the HashMap... or the JCS.. which ever you prefer.
>
I'll have to investigate JCS as soon as you send me your patch.
At the moment I have no preference. If JCS is included in the JRE or has
at least an EPL compatible license we could consider it as the default.
> [Eike] Is it possible to move the caching infrastructure from cdo.xyz
> to net4j.util?
> [Eike] It would be easier to reuse and it doesn't seem / shouldn't be
> dependent on CDO.
>
> I agree that it shouldn't be dependant of CDO... but
|
|
|
| Re: [CDO] [0.8.0] [message #94503 is a reply to message #94277] |
Tue, 28 August 2007 11:13 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0067_01C7E942.E73C23A0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fb0b17$odv$1@build.eclipse.org...
Simon McDuff schrieb:=20
Right now, in the framework We have one instance of =
IManagedContainer that configure everything.
The problem with that is to be able to create a different strategy =
to every Repository.. I will need one for each Repository... right ?
Yes, that seems reasonable.
Do you still want to have only one instance in the system or we can =
have more ?
Do you mean one instance of a repository per server?=20
[Simon] I mean, did you designed ManagedContainer to have only one =
instance and pass it around.. or It is a good design to have more than =
one
Then no, there can be arbitrary numbers of repositories in the server =
container.
They are created by the RepositoryConfigurator on server startup.
We would have to add config elements for the cache configuration...
[Simon] Yes=20
It will change my strategy... but if we can have more...
Repository would extends ManagedContainer.
Repository already extends IContainer: public interface IRepository =
extends IContainer<IRepositoryElement>
Do you really mean it should extend IManagedContainer?
[Simon] Because it already extend IContainer<IRepositoryElement> it =
would have to implement IManagedContainer, to have configuration related =
to Repository more flexible.
So every objects that Repository owns would be able to get a custom =
factory for any attributs in the future.
Could you explain a bit what you mean with that?
Which objects, which attributes?
[Simon] Repository contains many attributs. (PackageManager, =
Sessionmanager, ResourceManager, RevisionManager). Each of them have =
attributs as well.
So if we would like to configure these attributs and attributs owns by =
them... it will be easier because Repository already support such =
mechanism. (IManageContainer). If it is not IManageContainer, could be =
another factory mechanism.
I generally try to avoid components having dependencies on the wiring =
framework (IManagedContainer).
[Simon] ManagedContainer is a generic factory .... but maybe it does =
too much things for what I want to do.
But I must dmit that in some cases it would be easier with such a =
dependency. For example IConnector needs a way to create configurable =
protocols.
At the moment I pass in a FactoryRegistry and a PostProcessors list.=20
Originally it was only a FactoryRegistry which does not depend on =
IManageContainer.
But now that IElementProcessor is needed to configure IStreamWrappers =
I already have a dependency on IManagedContainer.
There are 3 resolutions:
1. Remove the IManagedContainer dependency from IElementProcessor (Not =
sure if that is good).
2. Replace FactoryRegistry and IElementProcessor by a full =
IManagedContainer reference.
3. Replace FactoryRegistry and IElementProcessor by a =
IProtocolProvider reference and have an implementation of this interface =
that uses an IManagedContainer.
I generally prefer the 3rd option at the moment since it gives full =
power of an IManagedContainer without having IConnector depend on =
IManagedContainer.
Also CDOSessionImpl will have as well a ManagedContainer (by =
composition) to take care of the CDOViewIMpl...and the=20
CDORevisionManagerImpl.
By Default I will put the HashMap... or the JCS.. which ever you =
prefer.
I'll have to investigate JCS as soon as you send me your patch.
At the moment I have no preference. If JCS is included in the JRE or =
has at least an EPL compatible license we could consider it as the =
default.
[Eike] Is it possible to move the caching infrastructure from =
cdo.xyz to net4j.util?
[Eike] It would be easier to reuse and it doesn't seem / shouldn't =
be dependent on CDO.
I agree that it shouldn't be dependant of CDO... but =CCt should'nt =
be dependant of Net4J as well :-) Right ?
I will put it under net4j.util.
That seems to be the best place for it ;-)
Cheers
/Eike
------=_NextPart_000_0067_01C7E942.E73C23A0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> wrote =
in message=20
<A=20
=
href=3D"news:fb0b17$odv$1@build.eclipse.org">news:fb0b17$odv$1@build.ecli=
pse.org</A>...</DIV>Simon=20
McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<DIV><FONT face=3DArial size=3D2>Right now, in the framework We have =
one=20
instance of IManagedContainer that configure =
everything.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>The problem with that is to be able =
to create a=20
different strategy to every Repository.. I will need one for each=20
Repository... right ?</FONT></DIV></BLOCKQUOTE>Yes, that seems=20
reasonable.<BR><BR>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>Do you still want to have only one=20
instance in the system or we can have more =
?</FONT></DIV></BLOCKQUOTE>
<DIV>Do you mean one instance of a repository per server? </DIV>
<DIV><STRONG>[Simon] I mean, did you designed ManagedContainer to have =
only=20
one instance and pass it around.. or It is a good design to have more =
than=20
one</STRONG><BR>Then no, there can be arbitrary numbers of =
repositories in the=20
server container.<BR>They are created by the RepositoryConfigurator on =
server=20
startup.<BR>We would have to add config elements for the cache=20
configuration...</DIV>
<DIV><STRONG>[Simon] Yes </STRONG><BR><BR></DIV>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>It will change my strategy... but =
if we can=20
have more...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>Repository =
</FONT>would extends=20
ManagedContainer.</FONT></DIV></BLOCKQUOTE>
<DIV>Repository already extends IContainer: public interface =
IRepository=20
extends IContainer<IRepositoryElement><BR>Do you really mean it =
should=20
extend IManagedContainer?<BR><STRONG>[Simon] Because it already extend =
IContainer<</STRONG>IRepositoryElement> it would have to =
implement=20
IManagedContainer<STRONG>, to have configuration related to Repository =
more=20
flexible.</STRONG></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So every objects that Repository owns =
would be=20
able to get a custom factory for any attributs in the=20
future.</FONT></DIV>
<DIV>Could you explain a bit what you mean with that?<BR>Which =
objects, which=20
attributes?</DIV><FONT color=3D#7f0055>
<P><FONT face=3DArial color=3D#000000 size=3D2><STRONG>[Simon] =
Repository contains=20
many attributs. (PackageManager, Sessionmanager, ResourceManager,=20
RevisionManager). Each of them have attributs as =
well.</STRONG></FONT></P>
<P></FONT><FONT face=3DArial size=3D2><STRONG>So if we would like to =
configure=20
these attributs and attributs owns by them... it will be easier =
because=20
Repository already support such mechanism. (IManageContainer). If it =
is not=20
IManageContainer, could be another factory =
mechanism.</STRONG></FONT></P>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2></FONT><BR>I generally try to avoid components having =
dependencies on=20
the wiring framework (IManagedContainer).</DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV><STRONG>[Simon] ManagedContainer is a generic factory .... but =
maybe it=20
does too much things for what I want to do.</STRONG></DIV>
=
<DIV><STRONG></STRONG><STRONG></STRONG><STRONG></STRONG ><STRONG></STRONG>=
<STRONG></STRONG><BR>But=20
I must dmit that in some cases it would be easier with such a =
dependency. For=20
example IConnector needs a way to create configurable protocols.<BR>At =
the=20
moment I pass in a FactoryRegistry and a PostProcessors list. =
<BR>Originally=20
it was only a FactoryRegistry which does not depend on=20
IManageContainer.<BR>But now that IElementProcessor is needed to =
configure=20
IStreamWrappers I already have a dependency on =
IManagedContainer.<BR>There are=20
3 resolutions:<BR>1. Remove the IManagedContainer dependency from=20
IElementProcessor (Not sure if that is good).<BR>2. Replace =
FactoryRegistry=20
and IElementProcessor by a full IManagedContainer reference.<BR>3. =
Replace=20
FactoryRegistry and IElementProcessor by a IProtocolProvider reference =
and=20
have an implementation of this interface that uses an=20
IManagedContainer.<BR><BR>I generally prefer the 3rd option at the =
moment=20
since it gives full power of an IManagedContainer without having =
IConnector=20
depend on IManagedContainer.<BR><BR></DIV>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV>
<P><FONT face=3DArial size=3D2>Also CDOSessionImpl will have as well =
a=20
ManagedContainer (by composition) to take care of the =
CDOViewIMpl...and=20
the </FONT></P>
<P><FONT face=3DArial size=3D2><FONT=20
size=3D2>CDORevisionManagerImpl.</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT size=3D2>By Default I will put =
the HashMap...=20
or the JCS.. which ever you =
prefer.</FONT></FONT></P></DIV></BLOCKQUOTE>I'll=20
have to investigate JCS as soon as you send me your patch.<BR>At the =
moment I=20
have no preference. If JCS is included in the JRE or has at least an =
EPL=20
compatible license we could consider it as the default.<BR><BR>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV>
<P><FONT face=3DArial size=3D2><FONT size=3D2>[Eike] Is it possible =
to move the=20
caching infrastructure from cdo.xyz to net4j.util?<BR>[Eike] It =
would be=20
easier to reuse and it doesn't seem / shouldn't be dependent on=20
CDO.</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT size=3D2>I agree that it =
shouldn't be=20
dependant of CDO... but =CCt should'nt be dependant of Net4J as well =
:-) Right=20
?</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT size=3D2>I will put it=20
under net4j.util.</FONT></FONT></P></DIV></BLOCKQUOTE >That =
seems to be=20
the best place for it=20
;-)<BR><BR>Cheers<BR>/Eike<BR><BR><BR></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_0067_01C7E942.E73C23A0--
|
|
|
| Re: [CDO] [0.8.0] [message #94739 is a reply to message #94503] |
Tue, 28 August 2007 20:05 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------070505080802070904070303
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Simon McDuff schrieb:
>
>
> "Eike Stepper" <stepper@sympedia.de <mailto:stepper@sympedia.de>>
> wrote in message news:fb0b17$odv$1@build.eclipse.org...
> Simon McDuff schrieb:
>> Right now, in the framework We have one instance of
>> IManagedContainer that configure everything.
>>
>> The problem with that is to be able to create a different
>> strategy to every Repository.. I will need one for each
>> Repository... right ?
> Yes, that seems reasonable.
>
>> Do you still want to have only one instance in the system or we
>> can have more ?
> Do you mean one instance of a repository per server?
> *[Simon] I mean, did you designed ManagedContainer to have only
> one instance and pass it around.. or It is a good design to have
> more than one*
>
ManagedContainer is not required to be a singleton.
Only IPluginContainer is an access point for one instance of
IManagedContainer that is configured through extension points. It is
only available if running in equinox.
> Then no, there can be arbitrary numbers of repositories in the
> server container.
> They are created by the RepositoryConfigurator on server startup.
> We would have to add config elements for the cache configuration...
> *[Simon] Yes *
>
>> It will change my strategy... but if we can have more...
>>
>>
>> Repository would extends ManagedContainer.
> Repository already extends IContainer: public interface
> IRepository extends IContainer<IRepositoryElement>
> Do you really mean it should extend IManagedContainer?
> *[Simon] Because it already extend IContainer<*IRepositoryElement>
> it would have to implement IManagedContainer*, to have
> configuration related to Repository more flexible.*
>
See my comments about "uninvasiveness" below.
>
> So every objects that Repository owns would be able to get a
> custom factory for any attributs in the future.
> Could you explain a bit what you mean with that?
> Which objects, which attributes?
>
> *[Simon] Repository contains many attributs. (PackageManager,
> Sessionmanager, ResourceManager, RevisionManager). Each of them
> have attributs as well.*
>
> *So if we would like to configure these attributs and attributs
> owns by them... it will be easier because Repository already
> support such mechanism. (IManageContainer). If it is not
> IManageContainer, could be another factory mechanism.*
>
By "configure" do you mean select the implementation class at runtime?
If yes, I'd rather suggest that we make the implementation class of
IRepository configurable via RepositoryConfigurator.
In addition we could provide factory methods for the IRepositoryElements
(except for store which is passed in via ctor).
>
> I generally try to avoid components having dependencies on the
> wiring framework (IManagedContainer).
> **
> *[Simon] ManagedContainer is a generic factory .... but maybe it
> does too much things for what I want to do.*
>
I think it's more because I'd like to be able to switch the wiring
implementation without touching all components.
Maybe in the future we decide to switch it to the OSGi service registry
or Spring or both...
> **********
> But I must dmit that in some cases it would be easier with such a
> dependency. For example IConnector needs a way to create
> configurable protocols.
> At the moment I pass in a FactoryRegistry and a PostProcessors list.
> Originally it was only a FactoryRegistry which does not depend on
> IManageContainer.
> But now that IElementProcessor is needed to configure
> IStreamWrappers I already have a dependency on IManagedContainer.
> There are 3 resolutions:
> 1. Remove the IManagedContainer dependency from IElementProcessor
> (Not sure if that is good).
> 2. Replace FactoryRegistry and IElementProcessor by a full
> IManagedContainer reference.
> 3. Replace FactoryRegistry and IElementProcessor by a
> IProtocolProvider reference and have an implementation of this
> interface that uses an IManagedContainer.
>
> I generally prefer the 3rd option at the moment since it gives
> full power of an IManagedContainer without having IConnector
> depend on IManagedContainer.
>
>> Also CDOSessionImpl will have as well a ManagedContainer (by
>> composition) to take care of the CDOViewIMpl...and the
>>
>> CDORevisionManagerImpl.
>>
>> By Default I will put the HashMap... or the JCS.. which ever you
>> prefer.
>>
> I'll have to investigate JCS as soon as you send me your patch.
> At the moment I have no preference. If JCS is included in the JRE
> or has at least an EPL compatible license we could consider it as
> the default.
>
>> [Eike] Is it possible to move the caching infrastructure from
>> cdo.xyz to net4j.util?
>> [Eike] It would be easier to reuse and it doesn't seem /
>> shouldn't be dependent on CDO.
>>
>> I agree that it shouldn't be dependant of CDO... but
|
|
|
| Re: [CDO] [0.8.0] [message #609514 is a reply to message #94032] |
Fri, 24 August 2007 14:09 |
|
Hi Simon,
Originally I planned to rework the various caches a bit later. But since
the IStore API seems to approach a pretty stable state we could consider
to optimize some non-functional aspects now.
I've already had a look into EHCache and some of its competitors and I
must admit that I was a bit disappointed that they are so simple. If I
remember correctly they only use separate files in a folder to store
objects.
Do you know how the various frameworks including JCS relate to each
other? Are there integrations between them?
In the end I think it'd be good if the caching provider could be
flexibly contributed.
I suggest that you send me your patches with JCS support and I review
them carefully.
Maybe I'm able to factor out the underlying caching system and make it
configurable.
An Apache license is a good starting position but I'm not allowed to
commit any third party (non-EPL) code prior to an official IP approval.
But don't worry, I'll manage that.
BTW. the work you've done on the OODB store implementation for CDO, will
you be able and willing to contribute it or is it protected by
copyrights of your employer?
Cheers
/Eike
Simon McDuff schrieb:
> hi Eike,
>
> We are deploying a version of your framework next week to our developper so
> they can start to use it.
> The only show stopper we have it is the management of memory. We always goes
> in a OUTOFMemoryException. Do you mind if I integrate JCS in the CDO
> Project?
>
> http://jakarta.apache.org/jcs/
>
> It is an open source project. I plan to put it in the client and server
> side.
> I will need also to add a new Store, IStoreReader, IStoreWriter to keep
> objects in memory for the testcase that we do not use any Store. Why ??
> Since the repository will not necessary have all the objects in its
> cache...We need a place to keep them. Make sense?
>
> What do you think.. do you mind ?
> If you agree.. how do you like to proceed ? I can send you all the file in
> patches so you can revised them.
> Or do you prefer that I keep modifications in my side ?
> Or any suggestions ?
>
>
> Simon
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] [0.8.0] [message #609517 is a reply to message #94094] |
Fri, 24 August 2007 14:53 |
|
Simon McDuff schrieb:
> JCS compare their products with EHCache
> http://jakarta.apache.org/jcs/JCSvsEHCache.html
>
I'll read it...
> You are right EHCache is very disappointed.
> JCS is very very powerful caching.. you can sotre on the disk.. but I will
> put the default to be only in memory.
>
> For the In-Memory implementation of the Store I will use JCS as well... but
> I will create object on the disk....
>
That doesn't make sense to me but maybe I don't understand what you mean ;-)
> JCS have also the capability to define region...
> Its region have their cache strategy..
> A region could be a EPackage or a EClass!!! So the user will have the
> control of their retentition like they want.
>
Sounds good.
When you're ready with your patch please attach it to an enhancement
request in Bugzilla.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] [0.8.0] [message #609519 is a reply to message #94122] |
Fri, 24 August 2007 15:18 |
|
This is a multi-part message in MIME format.
--------------000504090509060701050308
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
>>> For the In-Memory implementation of the Store I will use JCS as well...
>>> but I will create object on the disk....
>>>
>>>
>> That doesn't make sense to me but maybe I don't understand what you mean
>> ;-)
>>
>
> In you test case right now, when you create objects we assume that the
> server cache will keep objects after different transaction.
> But by adding JCS cache on the server and the client ... this isn't true
> anymore.
> It is possible that after creating objects and committed them... The server
> cache will discard some objects.
> When the other transaction will try to fetch an object... it will failed
> since the server cache will not have them anymore.
>
> By adding a In-Memory implementation.... It will assure that discarded
> objects are still available.
>
I see. I was a bit confused since for a complete in-memory
implementation of the server (aka RevisionManager) you only need to turn
off disk caching (when you have implemented it) and use a NOOPStore
(which I removed recently).
If I got you right you want to implement IStore backed by a disk based
JCS cache?
Cheers
/Eike
--------------000504090509060701050308
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:famrrg$ldq$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">For the In-Memory implementation of the Store I will use JCS as well...
but I will create object on the disk....
</pre>
</blockquote>
<pre wrap="">That doesn't make sense to me but maybe I don't understand what you mean
;-)
</pre>
</blockquote>
<pre wrap=""><!---->
In you test case right now, when you create objects we assume that the
server cache will keep objects after different transaction.
But by adding JCS cache on the server and the client ... this isn't true
anymore.
It is possible that after creating objects and committed them... The server
cache will discard some objects.
When the other transaction will try to fetch an object... it will failed
since the server cache will not have them anymore.
By adding a In-Memory implementation.... It will assure that discarded
objects are still available.
</pre>
</blockquote>
I see. I was a bit confused since for a
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [0.8.0] [message #609530 is a reply to message #94066] |
Sun, 26 August 2007 15:36 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_00D6_01C7E7D5.5A22AA20
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
Hi Eike,
I started the implementation of the JCS.
I expect to change the following maps
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions;
CDOViewImpl
private Map<CDOID, InternalCDOObject> objects;
I didn`t all complete it.. but let me know if you see a problem with =
that.
We have 3 contexts where caching is used.
Server side :
RevisionManager
Client side
CDOViewImpl
CDORevisionManagerImpl=20
I think only one of them should be using a factory pattern : =
RevisionManager. Because this is where people would like to have control =
because it is on the server side that it could be very slow. Let say =
when you deploy you could have many CDOServer and your caching =
strategy.. is sharing cache between all CDOServer.
I planned to use IManagedContainer to achieve that.
For the client side, we shouldn`t use factory.. but define an interface =
for parameters that we support
interface CDOCache
{
setMaxObjects()
getMaxObjects();
dropObjectCache();
isObjectCache();
}
CDOViewImpl and CDORevisionManagerImpl will implement them using JCS.
Let me know want you think ?
Do you think we should put flexibility to change the implementation in =
the client side as well ?
"Eike Stepper" <stepper@sympedia.de> a =E9crit dans le message de news: =
famopr$9pe$1@build.eclipse.org...
> Hi Simon,
>=20
> Originally I planned to rework the various caches a bit later. But =
since=20
> the IStore API seems to approach a pretty stable state we could =
consider=20
> to optimize some non-functional aspects now.
> I've already had a look into EHCache and some of its competitors and I =
> must admit that I was a bit disappointed that they are so simple. If I =
> remember correctly they only use separate files in a folder to store=20
> objects.
> Do you know how the various frameworks including JCS relate to each=20
> other? Are there integrations between them?
>=20
> In the end I think it'd be good if the caching provider could be=20
> flexibly contributed.
> I suggest that you send me your patches with JCS support and I review=20
> them carefully.
> Maybe I'm able to factor out the underlying caching system and make it =
> configurable.
>=20
> An Apache license is a good starting position but I'm not allowed to=20
> commit any third party (non-EPL) code prior to an official IP =
approval.
> But don't worry, I'll manage that.
>=20
> BTW. the work you've done on the OODB store implementation for CDO, =
will=20
> you be able and willing to contribute it or is it protected by=20
> copyrights of your employer?
>=20
> Cheers
> /Eike
>=20
>=20
> Simon McDuff schrieb:
>> hi Eike,
>>
>> We are deploying a version of your framework next week to our =
developper so=20
>> they can start to use it.
>> The only show stopper we have it is the management of memory. We =
always goes=20
>> in a OUTOFMemoryException. Do you mind if I integrate JCS in the CDO=20
>> Project?
>>
>> http://jakarta.apache.org/jcs/
>>
>> It is an open source project. I plan to put it in the client and =
server=20
>> side.
>> I will need also to add a new Store, IStoreReader, IStoreWriter to =
keep=20
>> objects in memory for the testcase that we do not use any Store. Why =
??=20
>> Since the repository will not necessary have all the objects in its=20
>> cache...We need a place to keep them. Make sense?
>>
>> What do you think.. do you mind ?
>> If you agree.. how do you like to proceed ? I can send you all the =
file in=20
>> patches so you can revised them.
>> Or do you prefer that I keep modifications in my side ?
>> Or any suggestions ?
>>
>>
>> Simon
>>
>>
>>
------=_NextPart_000_00D6_01C7E7D5.5A22AA20
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-15">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>Hi Eike,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I started the implementation of the=20
JCS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expect to change the following =
maps</FONT></DIV>
<DIV><U><FONT color=3D#0000ff size=3D2>
<P>CDORevisionResolverImpl</P></U></FONT></DIV>
<DIV><FONT size=3D2><B><FONT color=3D#7f0055 size=3D2>
<P>private</B></FONT><FONT size=3D2> Map<CDOID, TimeLine> =
</FONT><FONT=20
color=3D#0000c0 size=3D2>revisions</FONT><FONT size=3D2>;<FONT =
size=3D2></P>
<P>CDOViewImpl</P></FONT></FONT><FONT color=3D#0000c0 size=3D2><FONT =
size=3D2>
<P></FONT></FONT></FONT><FONT face=3DArial size=3D2><B><FONT =
color=3D#7f0055=20
size=3D2>private</B></FONT><FONT size=3D2> Map<CDOID, =
InternalCDOObject>=20
</FONT><FONT color=3D#0000c0 size=3D2>objects;</FONT></FONT><FONT =
face=3DArial=20
size=3D2></FONT></P></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn`t all complete it.. but let me =
know if you=20
see a problem with that.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>We have 3 contexts where caching is=20
used.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Server side :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RevisionManager</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Client side</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDORevisionManagerImpl </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I think only one of them should be =
using a factory=20
pattern : RevisionManager. Because this is where people would like to =
have=20
control because it is on the server side that it could be very =
slow. Let=20
say when you deploy you could have many CDOServer and your caching =
strategy.. is=20
sharing cache between all CDOServer.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I planned to use IManagedContainer to =
achieve=20
that.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>For the client side, we shouldn`t use =
factory.. but=20
define an interface for parameters that we support</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>interface CDOCache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
setMaxObjects()</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
getMaxObjects();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
dropObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
isObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT> and=20
CDORevisionManagerImpl will implement them using JCS.</DIV>
<DIV></FONT> </DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Let me know want you think =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you think we should put flexibility =
to change=20
the implementation in the client side as well ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"Eike Stepper" <</FONT><A=20
href=3D"mailto:stepper@sympedia.de"><FONT face=3DArial=20
size=3D2>stepper@sympedia.de</FONT></A><FONT face=3DArial size=3D2>> =
a =E9crit dans=20
le message de news: </FONT><A =
href=3D"mailto:famopr$9pe$1@build.eclipse.org"><FONT=20
face=3DArial size=3D2>famopr$9pe$1@build.eclipse.org</FONT></A><FONT =
face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> Hi =
Simon,<BR>> <BR>>=20
Originally I planned to rework the various caches a bit later. But since =
<BR>> the IStore API seems to approach a pretty stable state we could =
consider <BR>> to optimize some non-functional aspects now.<BR>> =
I've=20
already had a look into EHCache and some of its competitors and I =
<BR>> must=20
admit that I was a bit disappointed that they are so simple. If I =
<BR>>=20
remember correctly they only use separate files in a folder to store =
<BR>>=20
objects.<BR>> Do you know how the various frameworks including JCS =
relate to=20
each <BR>> other? Are there integrations between them?<BR>> =
<BR>> In=20
the end I think it'd be good if the caching provider could be <BR>> =
flexibly=20
contributed.<BR>> I suggest that you send me your patches with JCS =
support=20
and I review <BR>> them carefully.<BR>> Maybe I'm able to factor =
out the=20
underlying caching system and make it <BR>> configurable.<BR>> =
<BR>> An=20
Apache license is a good starting position but I'm not allowed to =
<BR>>=20
commit any third party (non-EPL) code prior to an official IP =
approval.<BR>>=20
But don't worry, I'll manage that.<BR>> <BR>> BTW. the work you've =
done on=20
the OODB store implementation for CDO, will <BR>> you be able and =
willing to=20
contribute it or is it protected by <BR>> copyrights of your=20
employer?<BR>> <BR>> Cheers<BR>> /Eike<BR>> <BR>> =
<BR>> Simon=20
McDuff schrieb:<BR>>> hi Eike,<BR>>><BR>>> =
We are=20
deploying a version of your framework next week to our developper so=20
<BR>>> they can start to use it.<BR>>> The only show stopper =
we have=20
it is the management of memory. We always goes <BR>>> in a=20
OUTOFMemoryException. Do you mind if I integrate JCS in the CDO =
<BR>>>=20
Project?<BR>>><BR>>> </FONT><A=20
href=3D"http://jakarta.apache.org/jcs/"><FONT face=3DArial=20
size=3D2>http://jakarta.apache.org/jcs/</FONT></A><BR><FONT face=3DArial =
size=3D2>>><BR>>> It is an open source project. I plan to =
put it in=20
the client and server <BR>>> side.<BR>>> I will need also to =
add a=20
new Store, IStoreReader, IStoreWriter to keep <BR>>> objects in =
memory for=20
the testcase that we do not use any Store. Why ?? <BR>>> Since the =
repository will not necessary have all the objects in its <BR>>>=20
cache...We need a place to keep them. Make =
sense?<BR>>><BR>>> What=20
do you think.. do you mind ?<BR>>> If you agree.. how do you like =
to=20
proceed ? I can send you all the file in <BR>>> patches so you can =
revised=20
them.<BR>>> Or do you prefer that I keep modifications in my side=20
?<BR>>> Or any suggestions ?<BR>>><BR>>><BR>>>=20
Simon<BR>>><BR>>><BR>>> </FONT></BODY></HTML>
------=_NextPart_000_00D6_01C7E7D5.5A22AA20--
|
|
|
| Re: [CDO] [0.8.0] [message #609540 is a reply to message #94243] |
Mon, 27 August 2007 15:05 |
|
This is a multi-part message in MIME format.
--------------050802030508060208090707
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Hi Simon,
See my comments inline...
Simon McDuff schrieb:
> Hi Eike,
>
> I started the implementation of the JCS.
> I expect to change the following maps
> _ _
>
> _CDORevisionResolverImpl_
>
> * *
>
> *private* Map<CDOID, TimeLine> revisions;
>
> CDOViewImpl
>
> *private* Map<CDOID, InternalCDOObject> objects;
>
>
> I didn`t all complete it.. but let me know if you see a problem with that.
>
> We have 3 contexts where caching is used.
>
> Server side :
> RevisionManager
>
> Client side
> CDOViewImpl
> CDORevisionManagerImpl
I'd start with RevisionManager and CDORevisionManagerImpl because they
hold big objects (revisions).
You'll notice that a revision manager does not directly hold the
revisions. Instead it holds TimeLine objects which in turn hold the
revisions.
> I think only one of them should be using a factory pattern :
> RevisionManager. Because this is where people would like to have
> control because it is on the server side that it could be very slow.
> Let say when you deploy you could have many CDOServer and your caching
> strategy.. is sharing cache between all CDOServer.
Maybe I don't fully understand the details of JCS (what exactly is a
"cache") but I can't imagine a rwason why we would want to share caches
between CDO servers.
Even cache sharing between the different repositories of a CDO server
doesn't seem a good idea.
> I planned to use IManagedContainer to achieve that.
That's generally a good idea ;-)
> For the client side, we shouldn`t use factory.. but define an
> interface for parameters that we support
>
> interface CDOCache
> {
> setMaxObjects()
> getMaxObjects();
> dropObjectCache();
> isObjectCache();
> }
Is it possible to move the caching infrastructure from cdo.xyz to
net4j.util?
It would be easier to reuse and it doesn't seem / shouldn't be dependent
on CDO.
>
> CDOViewImpl and CDORevisionManagerImpl will implement them using JCS.
>
> Let me know want you think ?
> Do you think we should put flexibility to change the implementation in
> the client side as well ?
In the end, yes.
But this is not urgent ;-)
Looking forwar to see what you'll develop!
Cheers
/Eike
--------------050802030508060208090707
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Simon,<br>
<br>
See my comments inline...<br>
<br>
<br>
Simon McDuff schrieb:
<blockquote cite="mid:fas6m2$km1$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div><font face="Arial" size="2">Hi Eike,</font></div>
<div>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [0.8.0] [message #609542 is a reply to message #94272] |
Tue, 28 August 2007 00:13 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_01BC_01C7E8E6.C544EFE0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
"Eike Stepper" <stepper@sympedia.de> a =E9crit dans le message de =
news: faup74$frt$4@build.eclipse.org...
Hi Simon,
See my comments inline...
Simon McDuff schrieb:=20
Hi Eike,
I started the implementation of the JCS.
I expect to change the following maps
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions;
CDOViewImpl
private Map<CDOID, InternalCDOObject> objects;
I didn`t all complete it.. but let me know if you see a problem with =
that.
We have 3 contexts where caching is used.
Server side :
RevisionManager
Client side
CDOViewImpl
CDORevisionManagerImpl
I'd start with RevisionManager and CDORevisionManagerImpl because they =
hold big objects (revisions).
You'll notice that a revision manager does not directly hold the =
revisions. Instead it holds TimeLine objects which in turn hold the =
revisions.
I think only one of them should be using a factory pattern : =
RevisionManager. Because this is where people would like to have control =
because it is on the server side that it could be very slow. Let say =
when you deploy you could have many CDOServer and your caching =
strategy.. is sharing cache between all CDOServer.
Maybe I don't fully understand the details of JCS (what exactly is a =
"cache") but I can't imagine a rwason why we would want to share caches =
between CDO servers.
Even cache sharing between the different repositories of a CDO server =
doesn't seem a good idea.
I planned to use IManagedContainer to achieve that.
That's generally a good idea ;-)
For the client side, we shouldn`t use factory.. but define an =
interface for parameters that we support
interface CDOCache
{
setMaxObjects()
getMaxObjects();
dropObjectCache();
isObjectCache();
}
Is it possible to move the caching infrastructure from cdo.xyz to =
net4j.util?
It would be easier to reuse and it doesn't seem / shouldn't be =
dependent on CDO.
CDOViewImpl and CDORevisionManagerImpl will implement them using =
JCS.
Let me know want you think ?
Do you think we should put flexibility to change the implementation =
in the client side as well ?
In the end, yes.
But this is not urgent ;-)
Looking forwar to see what you'll develop!
Cheers
/Eike
------=_NextPart_000_01BC_01C7E8E6.C544EFE0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> a =
=E9crit dans le=20
message de news: <A=20
=
href=3D"mailto:faup74$frt$4@build.eclipse.org">faup74$frt$4@build.eclipse=
..org</A>...</DIV>Hi=20
Simon,<BR><BR>See my comments inline...<BR><BR><BR>Simon McDuff =
schrieb:=20
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>Hi Eike,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I started the implementation of the =
JCS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expect to change the following=20
maps</FONT></DIV>
<DIV><U><FONT color=3D#0000ff size=3D2></FONT></U>
<P><U><FONT color=3D#0000ff=20
size=3D2>CDORevisionResolverImpl</FONT></U></P></DIV>
<DIV><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2></FONT></B></FONT>
<P><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2>private</FONT></B><FONT=20
size=3D2> Map<CDOID, TimeLine> </FONT><FONT color=3D#0000c0=20
size=3D2>revisions</FONT><FONT size=3D2>;</FONT></FONT></P>
<P><FONT size=3D2><FONT size=3D2><FONT=20
size=3D2>CDOViewImpl</FONT></FONT></FONT></P><FONT size=3D2><FONT =
color=3D#0000c0=20
size=3D2><FONT size=3D2></FONT></FONT></FONT>
<P><FONT face=3DArial size=3D2><B><FONT color=3D#7f0055=20
size=3D2>private</FONT></B><FONT size=3D2> Map<CDOID, =
InternalCDOObject>=20
</FONT><FONT color=3D#0000c0 =
size=3D2>objects;</FONT></FONT></P></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn`t all complete it.. but let =
me know if=20
you see a problem with that.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>We have 3 contexts where caching is =
used.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Server side :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RevisionManager</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Client side</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>CDORevisionManagerImpl</FONT></DIV></BLOCKQUOTE ><BR>I'd start =
with=20
RevisionManager and <FONT face=3DArial size=3D2>CDORevisionManagerImpl =
because=20
they hold big objects (revisions).<BR>You'll notice that a revision =
manager=20
does not directly hold the revisions. Instead it holds TimeLine =
objects which=20
in turn hold the revisions.<BR><BR></FONT>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2></FONT></DIV>
<DIV> <FONT face=3DArial size=3D2>I think only one of them =
should be using=20
a factory pattern : RevisionManager. Because this is where people =
would like=20
to have control because it is on the server side that it could =
be very=20
slow. Let say when you deploy you could have many CDOServer and your =
caching=20
strategy.. is sharing cache between all =
CDOServer.</FONT></DIV></BLOCKQUOTE>
<DIV>Maybe I don't fully understand the details of JCS (what exactly =
is a=20
"cache") but I can't imagine a rwason why we would want to share =
caches=20
between CDO servers.<BR>Even cache sharing between the different =
repositories=20
of a CDO server doesn't seem a good idea.<BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial=20
size=3D2></FONT><BR> </DIV>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>I planned to use IManagedContainer =
to achieve=20
that.</FONT></DIV></BLOCKQUOTE>That's generally a good idea =
;-)<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>For the client side, we shouldn`t =
use factory..=20
but define an interface for parameters that we support</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>interface CDOCache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
setMaxObjects()</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
getMaxObjects();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
dropObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
isObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV></BLOCKQUOTE>Is it =
possible to move=20
the caching infrastructure from cdo.xyz to net4j.util?<BR>It would be =
easier=20
to reuse and it doesn't seem / shouldn't be dependent on CDO.<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2>CDOViewImpl</FONT> and =
CDORevisionManagerImpl will=20
implement them using JCS.</FONT></DIV>
<DIV> </DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Let me know want you think =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you think we should put =
flexibility to=20
change the implementation in the client side as well=20
?</FONT></DIV></BLOCKQUOTE>In the end, yes.<BR>But this is not urgent=20
;-)<BR><BR>Looking forwar to see what you'll=20
develop!<BR><BR>Cheers<BR>/Eike<BR><BR></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_01BC_01C7E8E6.C544EFE0--
|
|
|
| Re: [CDO] [0.8.0] [message #609543 is a reply to message #94272] |
Tue, 28 August 2007 00:27 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_01D2_01C7E8E8.A0AF2CC0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
Right now, in the framework We have one instance of IManagedContainer =
that configure everything.
The problem with that is to be able to create a different strategy to =
every Repository.. I will need one for each Repository... right ?
Do you still want to have only one instance in the system or we can have =
more ?
It will change my strategy... but if we can have more...
Repository would extends ManagedContainer.
So every objects that Repository owns would be able to get a custom =
factory for any attributs in the future.
Also CDOSessionImpl will have as well a ManagedContainer (by =
composition) to take care of the CDOViewIMpl...and the=20
CDORevisionManagerImpl.
By Default I will put the HashMap... or the JCS.. which ever you prefer.
[Eike] Is it possible to move the caching infrastructure from cdo.xyz to =
net4j.util?
[Eike] It would be easier to reuse and it doesn't seem / shouldn't be =
dependent on CDO.
I agree that it shouldn't be dependant of CDO... but =CCt should'nt be =
dependant of Net4J as well :-) Right ?
I will put it under net4j.util.
"Eike Stepper" <stepper@sympedia.de> a =E9crit dans le message de =
news: faup74$frt$4@build.eclipse.org...
Hi Simon,
See my comments inline...
Simon McDuff schrieb:=20
Hi Eike,
I started the implementation of the JCS.
I expect to change the following maps
CDORevisionResolverImpl
private Map<CDOID, TimeLine> revisions;
CDOViewImpl
private Map<CDOID, InternalCDOObject> objects;
I didn`t all complete it.. but let me know if you see a problem with =
that.
We have 3 contexts where caching is used.
Server side :
RevisionManager
Client side
CDOViewImpl
CDORevisionManagerImpl
I'd start with RevisionManager and CDORevisionManagerImpl because they =
hold big objects (revisions).
You'll notice that a revision manager does not directly hold the =
revisions. Instead it holds TimeLine objects which in turn hold the =
revisions.
I think only one of them should be using a factory pattern : =
RevisionManager. Because this is where people would like to have control =
because it is on the server side that it could be very slow. Let say =
when you deploy you could have many CDOServer and your caching =
strategy.. is sharing cache between all CDOServer.
Maybe I don't fully understand the details of JCS (what exactly is a =
"cache") but I can't imagine a rwason why we would want to share caches =
between CDO servers.
Even cache sharing between the different repositories of a CDO server =
doesn't seem a good idea.
I planned to use IManagedContainer to achieve that.
That's generally a good idea ;-)
For the client side, we shouldn`t use factory.. but define an =
interface for parameters that we support
interface CDOCache
{
setMaxObjects()
getMaxObjects();
dropObjectCache();
isObjectCache();
}
Is it possible to move the caching infrastructure from cdo.xyz to =
net4j.util?
It would be easier to reuse and it doesn't seem / shouldn't be =
dependent on CDO.
CDOViewImpl and CDORevisionManagerImpl will implement them using =
JCS.
Let me know want you think ?
Do you think we should put flexibility to change the implementation =
in the client side as well ?
In the end, yes.
But this is not urgent ;-)
Looking forwar to see what you'll develop!
Cheers
/Eike
------=_NextPart_000_01D2_01C7E8E8.A0AF2CC0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Right now, in the framework We have one =
instance of=20
IManagedContainer that configure everything.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The problem with that is to be able to =
create a=20
different strategy to every Repository.. I will need one for each =
Repository...=20
right ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Do you still want to have only one =
instance in=20
the system or we can have more ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It will change my strategy... but if we =
can have=20
more...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>Repository </FONT>would =
extends=20
ManagedContainer.</DIV>
<DIV>
<P>So every objects that Repository owns would be able to get a=20
custom factory for any attributs in the future.</P>
<P>Also CDOSessionImpl will have as well a ManagedContainer (by =
composition)=20
to take care of the CDOViewIMpl...and the <FONT size=3D2></P>
<P>CDORevisionManagerImpl.</P>
<P>By Default I will put the HashMap... or the JCS.. which ever you =
prefer.</P>
<P>[Eike] Is it possible to move the caching infrastructure from cdo.xyz =
to=20
net4j.util?<BR>[Eike] It would be easier to reuse and it doesn't seem /=20
shouldn't be dependent on CDO.</P>
<P>I agree that it shouldn't be dependant of CDO... but =CCt should'nt =
be=20
dependant of Net4J as well :-) Right ?</P>
<P>I will put it under net4j.util.</P>
<P> </P>
<P></FONT> </P>
<P></FONT> </P></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> a =
=E9crit dans le=20
message de news: <A=20
=
href=3D"mailto:faup74$frt$4@build.eclipse.org">faup74$frt$4@build.eclipse=
..org</A>...</DIV>Hi=20
Simon,<BR><BR>See my comments inline...<BR><BR><BR>Simon McDuff =
schrieb:=20
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
<DIV><FONT face=3DArial size=3D2>Hi Eike,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I started the implementation of the =
JCS.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I expect to change the following=20
maps</FONT></DIV>
<DIV><U><FONT color=3D#0000ff size=3D2></FONT></U>
<P><U><FONT color=3D#0000ff=20
size=3D2>CDORevisionResolverImpl</FONT></U></P></DIV>
<DIV><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2></FONT></B></FONT>
<P><FONT size=3D2><B><FONT color=3D#7f0055 =
size=3D2>private</FONT></B><FONT=20
size=3D2> Map<CDOID, TimeLine> </FONT><FONT color=3D#0000c0=20
size=3D2>revisions</FONT><FONT size=3D2>;</FONT></FONT></P>
<P><FONT size=3D2><FONT size=3D2><FONT=20
size=3D2>CDOViewImpl</FONT></FONT></FONT></P><FONT size=3D2><FONT =
color=3D#0000c0=20
size=3D2><FONT size=3D2></FONT></FONT></FONT>
<P><FONT face=3DArial size=3D2><B><FONT color=3D#7f0055=20
size=3D2>private</FONT></B><FONT size=3D2> Map<CDOID, =
InternalCDOObject>=20
</FONT><FONT color=3D#0000c0 =
size=3D2>objects;</FONT></FONT></P></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>I didn`t all complete it.. but let =
me know if=20
you see a problem with that.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>We have 3 contexts where caching is =
used.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Server side :</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>RevisionManager</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>Client side</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>CDOViewImpl</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>CDORevisionManagerImpl</FONT></DIV></BLOCKQUOTE ><BR>I'd start =
with=20
RevisionManager and <FONT face=3DArial size=3D2>CDORevisionManagerImpl =
because=20
they hold big objects (revisions).<BR>You'll notice that a revision =
manager=20
does not directly hold the revisions. Instead it holds TimeLine =
objects which=20
in turn hold the revisions.<BR><BR></FONT>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2></FONT></DIV>
<DIV> <FONT face=3DArial size=3D2>I think only one of them =
should be using=20
a factory pattern : RevisionManager. Because this is where people =
would like=20
to have control because it is on the server side that it could =
be very=20
slow. Let say when you deploy you could have many CDOServer and your =
caching=20
strategy.. is sharing cache between all =
CDOServer.</FONT></DIV></BLOCKQUOTE>
<DIV>Maybe I don't fully understand the details of JCS (what exactly =
is a=20
"cache") but I can't imagine a rwason why we would want to share =
caches=20
between CDO servers.<BR>Even cache sharing between the different =
repositories=20
of a CDO server doesn't seem a good idea.<BR></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I planned to use IManagedContainer to =
achieve=20
that.</FONT></DIV>That's generally a good idea ;-)<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>For the client side, we shouldn`t =
use factory..=20
but define an interface for parameters that we support</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>interface CDOCache</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =
setMaxObjects()</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
getMaxObjects();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
dropObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> =20
isObjectCache();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV></BLOCKQUOTE>Is it =
possible to move=20
the caching infrastructure from cdo.xyz to net4j.util?<BR>It would be =
easier=20
to reuse and it doesn't seem / shouldn't be dependent on CDO.<BR><BR>
<BLOCKQUOTE cite=3Dmid:fas6m2$km1$1@build.eclipse.org type=3D"cite">
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial=20
size=3D2>CDOViewImpl</FONT> and =
CDORevisionManagerImpl will=20
implement them using JCS.</FONT></DIV>
<DIV> </DIV></DIV>
<DIV><FONT face=3DArial size=3D2>Let me know want you think =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Do you think we should put =
flexibility to=20
change the implementation in the client side as well=20
?</FONT></DIV></BLOCKQUOTE>In the end, yes.<BR>But this is not urgent=20
;-)<BR><BR>Looking forwar to see what you'll=20
develop!<BR><BR>Cheers<BR>/Eike<BR><BR></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_01D2_01C7E8E8.A0AF2CC0--
|
|
|
| Re: [CDO] [0.8.0] [message #609545 is a reply to message #94275] |
Tue, 28 August 2007 05:15 |
|
This is a multi-part message in MIME format.
--------------080402090409020309020409
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Simon McDuff schrieb:
> Right now, in the framework We have one instance of IManagedContainer
> that configure everything.
>
> The problem with that is to be able to create a different strategy to
> every Repository.. I will need one for each Repository... right ?
Yes, that seems reasonable.
> Do you still want to have only one instance in the system or we can
> have more ?
Do you mean one instance of a repository per server?
Then no, there can be arbitrary numbers of repositories in the server
container.
They are created by the RepositoryConfigurator on server startup.
We would have to add config elements for the cache configuration...
> It will change my strategy... but if we can have more...
>
>
> Repository would extends ManagedContainer.
Repository already extends IContainer: public interface IRepository
extends IContainer<IRepositoryElement>
Do you really mean it should extend IManagedContainer?
> So every objects that Repository owns would be able to get a
> custom factory for any attributs in the future.
>
Could you explain a bit what you mean with that?
Which objects, which attributes?
I generally try to avoid components having dependencies on the wiring
framework (IManagedContainer).
But I must dmit that in some cases it would be easier with such a
dependency. For example IConnector needs a way to create configurable
protocols.
At the moment I pass in a FactoryRegistry and a PostProcessors list.
Originally it was only a FactoryRegistry which does not depend on
IManageContainer.
But now that IElementProcessor is needed to configure IStreamWrappers I
already have a dependency on IManagedContainer.
There are 3 resolutions:
1. Remove the IManagedContainer dependency from IElementProcessor (Not
sure if that is good).
2. Replace FactoryRegistry and IElementProcessor by a full
IManagedContainer reference.
3. Replace FactoryRegistry and IElementProcessor by a IProtocolProvider
reference and have an implementation of this interface that uses an
IManagedContainer.
I generally prefer the 3rd option at the moment since it gives full
power of an IManagedContainer without having IConnector depend on
IManagedContainer.
> Also CDOSessionImpl will have as well a ManagedContainer (by
> composition) to take care of the CDOViewIMpl...and the
>
> CDORevisionManagerImpl.
>
> By Default I will put the HashMap... or the JCS.. which ever you prefer.
>
I'll have to investigate JCS as soon as you send me your patch.
At the moment I have no preference. If JCS is included in the JRE or has
at least an EPL compatible license we could consider it as the default.
> [Eike] Is it possible to move the caching infrastructure from cdo.xyz
> to net4j.util?
> [Eike] It would be easier to reuse and it doesn't seem / shouldn't be
> dependent on CDO.
>
> I agree that it shouldn't be dependant of CDO... but
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [0.8.0] [message #609556 is a reply to message #94277] |
Tue, 28 August 2007 11:13 |
Simon Mc Duff
Messages: 596
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0067_01C7E942.E73C23A0
Content-Type: text/plain;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fb0b17$odv$1@build.eclipse.org...
Simon McDuff schrieb:=20
Right now, in the framework We have one instance of =
IManagedContainer that configure everything.
The problem with that is to be able to create a different strategy =
to every Repository.. I will need one for each Repository... right ?
Yes, that seems reasonable.
Do you still want to have only one instance in the system or we can =
have more ?
Do you mean one instance of a repository per server?=20
[Simon] I mean, did you designed ManagedContainer to have only one =
instance and pass it around.. or It is a good design to have more than =
one
Then no, there can be arbitrary numbers of repositories in the server =
container.
They are created by the RepositoryConfigurator on server startup.
We would have to add config elements for the cache configuration...
[Simon] Yes=20
It will change my strategy... but if we can have more...
Repository would extends ManagedContainer.
Repository already extends IContainer: public interface IRepository =
extends IContainer<IRepositoryElement>
Do you really mean it should extend IManagedContainer?
[Simon] Because it already extend IContainer<IRepositoryElement> it =
would have to implement IManagedContainer, to have configuration related =
to Repository more flexible.
So every objects that Repository owns would be able to get a custom =
factory for any attributs in the future.
Could you explain a bit what you mean with that?
Which objects, which attributes?
[Simon] Repository contains many attributs. (PackageManager, =
Sessionmanager, ResourceManager, RevisionManager). Each of them have =
attributs as well.
So if we would like to configure these attributs and attributs owns by =
them... it will be easier because Repository already support such =
mechanism. (IManageContainer). If it is not IManageContainer, could be =
another factory mechanism.
I generally try to avoid components having dependencies on the wiring =
framework (IManagedContainer).
[Simon] ManagedContainer is a generic factory .... but maybe it does =
too much things for what I want to do.
But I must dmit that in some cases it would be easier with such a =
dependency. For example IConnector needs a way to create configurable =
protocols.
At the moment I pass in a FactoryRegistry and a PostProcessors list.=20
Originally it was only a FactoryRegistry which does not depend on =
IManageContainer.
But now that IElementProcessor is needed to configure IStreamWrappers =
I already have a dependency on IManagedContainer.
There are 3 resolutions:
1. Remove the IManagedContainer dependency from IElementProcessor (Not =
sure if that is good).
2. Replace FactoryRegistry and IElementProcessor by a full =
IManagedContainer reference.
3. Replace FactoryRegistry and IElementProcessor by a =
IProtocolProvider reference and have an implementation of this interface =
that uses an IManagedContainer.
I generally prefer the 3rd option at the moment since it gives full =
power of an IManagedContainer without having IConnector depend on =
IManagedContainer.
Also CDOSessionImpl will have as well a ManagedContainer (by =
composition) to take care of the CDOViewIMpl...and the=20
CDORevisionManagerImpl.
By Default I will put the HashMap... or the JCS.. which ever you =
prefer.
I'll have to investigate JCS as soon as you send me your patch.
At the moment I have no preference. If JCS is included in the JRE or =
has at least an EPL compatible license we could consider it as the =
default.
[Eike] Is it possible to move the caching infrastructure from =
cdo.xyz to net4j.util?
[Eike] It would be easier to reuse and it doesn't seem / shouldn't =
be dependent on CDO.
I agree that it shouldn't be dependant of CDO... but =CCt should'nt =
be dependant of Net4J as well :-) Right ?
I will put it under net4j.util.
That seems to be the best place for it ;-)
Cheers
/Eike
------=_NextPart_000_0067_01C7E942.E73C23A0
Content-Type: text/html;
charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" <<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>> wrote =
in message=20
<A=20
=
href=3D"news:fb0b17$odv$1@build.eclipse.org">news:fb0b17$odv$1@build.ecli=
pse.org</A>...</DIV>Simon=20
McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<DIV><FONT face=3DArial size=3D2>Right now, in the framework We have =
one=20
instance of IManagedContainer that configure =
everything.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>The problem with that is to be able =
to create a=20
different strategy to every Repository.. I will need one for each=20
Repository... right ?</FONT></DIV></BLOCKQUOTE>Yes, that seems=20
reasonable.<BR><BR>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>Do you still want to have only one=20
instance in the system or we can have more =
?</FONT></DIV></BLOCKQUOTE>
<DIV>Do you mean one instance of a repository per server? </DIV>
<DIV><STRONG>[Simon] I mean, did you designed ManagedContainer to have =
only=20
one instance and pass it around.. or It is a good design to have more =
than=20
one</STRONG><BR>Then no, there can be arbitrary numbers of =
repositories in the=20
server container.<BR>They are created by the RepositoryConfigurator on =
server=20
startup.<BR>We would have to add config elements for the cache=20
configuration...</DIV>
<DIV><STRONG>[Simon] Yes </STRONG><BR><BR></DIV>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV><FONT face=3DArial size=3D2>It will change my strategy... but =
if we can=20
have more...</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><FONT size=3D2>Repository =
</FONT>would extends=20
ManagedContainer.</FONT></DIV></BLOCKQUOTE>
<DIV>Repository already extends IContainer: public interface =
IRepository=20
extends IContainer<IRepositoryElement><BR>Do you really mean it =
should=20
extend IManagedContainer?<BR><STRONG>[Simon] Because it already extend =
IContainer<</STRONG>IRepositoryElement> it would have to =
implement=20
IManagedContainer<STRONG>, to have configuration related to Repository =
more=20
flexible.</STRONG></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>So every objects that Repository owns =
would be=20
able to get a custom factory for any attributs in the=20
future.</FONT></DIV>
<DIV>Could you explain a bit what you mean with that?<BR>Which =
objects, which=20
attributes?</DIV><FONT color=3D#7f0055>
<P><FONT face=3DArial color=3D#000000 size=3D2><STRONG>[Simon] =
Repository contains=20
many attributs. (PackageManager, Sessionmanager, ResourceManager,=20
RevisionManager). Each of them have attributs as =
well.</STRONG></FONT></P>
<P></FONT><FONT face=3DArial size=3D2><STRONG>So if we would like to =
configure=20
these attributs and attributs owns by them... it will be easier =
because=20
Repository already support such mechanism. (IManageContainer). If it =
is not=20
IManageContainer, could be another factory =
mechanism.</STRONG></FONT></P>
<DIV><FONT face=3DArial size=3D2></FONT><FONT face=3DArial =
size=3D2></FONT><FONT=20
face=3DArial size=3D2></FONT><FONT face=3DArial size=3D2></FONT><FONT =
face=3DArial=20
size=3D2></FONT><BR>I generally try to avoid components having =
dependencies on=20
the wiring framework (IManagedContainer).</DIV>
<DIV><STRONG></STRONG> </DIV>
<DIV><STRONG>[Simon] ManagedContainer is a generic factory .... but =
maybe it=20
does too much things for what I want to do.</STRONG></DIV>
=
<DIV><STRONG></STRONG><STRONG></STRONG><STRONG></STRONG ><STRONG></STRONG>=
<STRONG></STRONG><BR>But=20
I must dmit that in some cases it would be easier with such a =
dependency. For=20
example IConnector needs a way to create configurable protocols.<BR>At =
the=20
moment I pass in a FactoryRegistry and a PostProcessors list. =
<BR>Originally=20
it was only a FactoryRegistry which does not depend on=20
IManageContainer.<BR>But now that IElementProcessor is needed to =
configure=20
IStreamWrappers I already have a dependency on =
IManagedContainer.<BR>There are=20
3 resolutions:<BR>1. Remove the IManagedContainer dependency from=20
IElementProcessor (Not sure if that is good).<BR>2. Replace =
FactoryRegistry=20
and IElementProcessor by a full IManagedContainer reference.<BR>3. =
Replace=20
FactoryRegistry and IElementProcessor by a IProtocolProvider reference =
and=20
have an implementation of this interface that uses an=20
IManagedContainer.<BR><BR>I generally prefer the 3rd option at the =
moment=20
since it gives full power of an IManagedContainer without having =
IConnector=20
depend on IManagedContainer.<BR><BR></DIV>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV>
<P><FONT face=3DArial size=3D2>Also CDOSessionImpl will have as well =
a=20
ManagedContainer (by composition) to take care of the =
CDOViewIMpl...and=20
the </FONT></P>
<P><FONT face=3DArial size=3D2><FONT=20
size=3D2>CDORevisionManagerImpl.</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT size=3D2>By Default I will put =
the HashMap...=20
or the JCS.. which ever you =
prefer.</FONT></FONT></P></DIV></BLOCKQUOTE>I'll=20
have to investigate JCS as soon as you send me your patch.<BR>At the =
moment I=20
have no preference. If JCS is included in the JRE or has at least an =
EPL=20
compatible license we could consider it as the default.<BR><BR>
<BLOCKQUOTE cite=3Dmid:favq4o$7a9$1@build.eclipse.org type=3D"cite">
<DIV>
<P><FONT face=3DArial size=3D2><FONT size=3D2>[Eike] Is it possible =
to move the=20
caching infrastructure from cdo.xyz to net4j.util?<BR>[Eike] It =
would be=20
easier to reuse and it doesn't seem / shouldn't be dependent on=20
CDO.</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT size=3D2>I agree that it =
shouldn't be=20
dependant of CDO... but =CCt should'nt be dependant of Net4J as well =
:-) Right=20
?</FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT size=3D2>I will put it=20
under net4j.util.</FONT></FONT></P></DIV></BLOCKQUOTE >That =
seems to be=20
the best place for it=20
;-)<BR><BR>Cheers<BR>/Eike<BR><BR><BR></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_0067_01C7E942.E73C23A0--
|
|
|
| Re: [CDO] [0.8.0] [message #609571 is a reply to message #94503] |
Tue, 28 August 2007 20:05 |
|
This is a multi-part message in MIME format.
--------------070505080802070904070303
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Simon McDuff schrieb:
>
>
> "Eike Stepper" <stepper@sympedia.de <mailto:stepper@sympedia.de>>
> wrote in message news:fb0b17$odv$1@build.eclipse.org...
> Simon McDuff schrieb:
>> Right now, in the framework We have one instance of
>> IManagedContainer that configure everything.
>>
>> The problem with that is to be able to create a different
>> strategy to every Repository.. I will need one for each
>> Repository... right ?
> Yes, that seems reasonable.
>
>> Do you still want to have only one instance in the system or we
>> can have more ?
> Do you mean one instance of a repository per server?
> *[Simon] I mean, did you designed ManagedContainer to have only
> one instance and pass it around.. or It is a good design to have
> more than one*
>
ManagedContainer is not required to be a singleton.
Only IPluginContainer is an access point for one instance of
IManagedContainer that is configured through extension points. It is
only available if running in equinox.
> Then no, there can be arbitrary numbers of repositories in the
> server container.
> They are created by the RepositoryConfigurator on server startup.
> We would have to add config elements for the cache configuration...
> *[Simon] Yes *
>
>> It will change my strategy... but if we can have more...
>>
>>
>> Repository would extends ManagedContainer.
> Repository already extends IContainer: public interface
> IRepository extends IContainer<IRepositoryElement>
> Do you really mean it should extend IManagedContainer?
> *[Simon] Because it already extend IContainer<*IRepositoryElement>
> it would have to implement IManagedContainer*, to have
> configuration related to Repository more flexible.*
>
See my comments about "uninvasiveness" below.
>
> So every objects that Repository owns would be able to get a
> custom factory for any attributs in the future.
> Could you explain a bit what you mean with that?
> Which objects, which attributes?
>
> *[Simon] Repository contains many attributs. (PackageManager,
> Sessionmanager, ResourceManager, RevisionManager). Each of them
> have attributs as well.*
>
> *So if we would like to configure these attributs and attributs
> owns by them... it will be easier because Repository already
> support such mechanism. (IManageContainer). If it is not
> IManageContainer, could be another factory mechanism.*
>
By "configure" do you mean select the implementation class at runtime?
If yes, I'd rather suggest that we make the implementation class of
IRepository configurable via RepositoryConfigurator.
In addition we could provide factory methods for the IRepositoryElements
(except for store which is passed in via ctor).
>
> I generally try to avoid components having dependencies on the
> wiring framework (IManagedContainer).
> **
> *[Simon] ManagedContainer is a generic factory .... but maybe it
> does too much things for what I want to do.*
>
I think it's more because I'd like to be able to switch the wiring
implementation without touching all components.
Maybe in the future we decide to switch it to the OSGi service registry
or Spring or both...
> **********
> But I must dmit that in some cases it would be easier with such a
> dependency. For example IConnector needs a way to create
> configurable protocols.
> At the moment I pass in a FactoryRegistry and a PostProcessors list.
> Originally it was only a FactoryRegistry which does not depend on
> IManageContainer.
> But now that IElementProcessor is needed to configure
> IStreamWrappers I already have a dependency on IManagedContainer.
> There are 3 resolutions:
> 1. Remove the IManagedContainer dependency from IElementProcessor
> (Not sure if that is good).
> 2. Replace FactoryRegistry and IElementProcessor by a full
> IManagedContainer reference.
> 3. Replace FactoryRegistry and IElementProcessor by a
> IProtocolProvider reference and have an implementation of this
> interface that uses an IManagedContainer.
>
> I generally prefer the 3rd option at the moment since it gives
> full power of an IManagedContainer without having IConnector
> depend on IManagedContainer.
>
>> Also CDOSessionImpl will have as well a ManagedContainer (by
>> composition) to take care of the CDOViewIMpl...and the
>>
>> CDORevisionManagerImpl.
>>
>> By Default I will put the HashMap... or the JCS.. which ever you
>> prefer.
>>
> I'll have to investigate JCS as soon as you send me your patch.
> At the moment I have no preference. If JCS is included in the JRE
> or has at least an EPL compatible license we could consider it as
> the default.
>
>> [Eike] Is it possible to move the caching infrastructure from
>> cdo.xyz to net4j.util?
>> [Eike] It would be easier to reuse and it doesn't seem /
>> shouldn't be dependent on CDO.
>>
>> I agree that it shouldn't be dependant of CDO... but
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Thu Apr 25 02:22:36 GMT 2024
Powered by FUDForum. Page generated in 0.05007 seconds |
] 
Search
Help
Register
Login
Home
