Win a copy of OCP Oracle Certified Professional Java SE 11 Developer Practice Tests this week in the OCP forum!

lev grevnin

Ranch Hand
+ Follow
since Jan 23, 2003
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by lev grevnin

Hi all! I am almost done studying for the exam and now i am on EJB environment. The concept of JNDI context is apparently a fundamental one, and it's critically important to know precisely what it is. I am yet to see a clear, meaningful and full explanation of what a JNDI context is. Can you guys help me out, please, and give me a good explanation of what a JNDI contect really is. This would solve many of my confusions about the EJB environment. thanks much
Hi all! Does anyone know what those white bars mean that go across relationship arrows on page 150 of sun's ejb2.0 spec? I have no idea what the hell they mean. This is very irritating. Thanks for any help!!
Big Thanks for everyone's replies!
Guys. Please disregard my previous posting. It's way too confusing and all over the place, plus i have solved most of this. My question for now is this: how come in the specification exerpt mentioned in my previous posting they don't discuss the one-to-many relationship case? I believe, that an accessor method for one-to-many relationship to the entity will as well return a collection from which the entity object has been removed. Can someone comment on that please. Thanks -lev
Hey all. Happy New Year. I have a question, maybe someone can privide some insight into this.
The spec says (page 138): Once an entity has been removed from a relationship, the accessor methods for any relationships to the entity will reflect this removal. An accessor method for a one-to-one or many-to-one relationship to the entity will return null; and an accessor method for a many-to-many relationship to the entity will return a collection from which the entity object has been removed.
1) First of all, what's the direction of the relationship they are talking about? It wouldn't matter for one-to-one, but what about many-to-one? Is it from the bean that's removed to the other bean??? What about one-to-many, how come it is not mentioned at all in that paragraph?
2) If bean A is in the many-to-one relationship with bean B (i am thinking many beans A are contained by 1 bean B and only 1 bean B is contained by 1 bean A, just like the Movies-Director example from Kathy's book) and bean A gets removed, then how come the accessor for bean A in bean B (according to the spec) will return a null, and only if these two guys were in the many-to-many relationship would it return the collection from which A came from? I thought that in the many-to-one case the accessor for bean A in bean B would also return the collection of As (without the removed instance of A in my example)...
I would greately appreciate any help. This is driving me nuts. I cant resolve this point. thanks MUCH!
-lev g.

Each of 20 instances of the connection object wraps the same instance of the lock manager. Therefore, when a client mutates the instance of the lock manager, every other client now points to a mutated object.

This is entirely correct. However, this will only be true if any modification to the LockManager is done INSIDE the Connection's methods, called by client (so yeah, effectively it's the client which is initiating the change). If however, a client gets a LockManager object (must be Serializable) from Connection object, as in connection.getLockManager(), this LockManager object will be a COPY of the one shared internally between all Connections, and any changes to it will NOT be visible to the rest of the Connection objects. I actually tested this and it worked exactly as i described.
Just wanted to add this small comment/clarification.
Thanks Eugene. Your comments clarified things a lot.
Eugene, thanks a lot. Your reply was very helpful. It actually did clarify some of the things i was confused about. However... Imagine this situation:
On the client side i do:

will other clients (who will get their own Connection objects from ConnectionFactory) see the addition of the record # 123 to their LockManager's Map? It should be the same LockManager object for all Connection objects, I suppose, right? But if the LockManager is not a remote object, its COPY will be returned by connection.getLockManager() (for that to happen, LockManager has to be serializable of course). So how can any change done by one client on LockManager be visible to the other clients? (other than by performing lock() INSIDE one of Connection object's methods, because, indeed, this operation will be local to the server's JVM and EVERY Connection object on the client side will see this change)
any comments would help.
Hey all,
Just a quick clarification question. I didn't code it yet, but my ConnectionFactory (a remote object) returns a new Connection to each client (also a remote object). When Connection is created by ConnectionFactory it gives it a LockManager object (a private instance of ConnectionFactory). Suppose a few clients access the ConnectionFactory, grab their own Connection object and get a LockManager object out of it to perform lock() unlock() operations on it. My question is: does LockManager also need to be a remote object, or if i don't make it a remote object what each client will get from connectionInstance.getLockManager() will be just a copy of the private LockManager instance from the ConnectionFactory, and any changes made by one client to its (LockManager's) internal Map (the Map is used to track who owns which record) will not be visible to other clients LockManager internal Maps?
[ March 12, 2003: Message edited by: lev grevnin ]
[ March 12, 2003: Message edited by: lev grevnin ]
Mark, thanks for your reply. I actually remember from one of the posts that this was the source of your confusion too in the past. I actually solved my problem already and put it into code, which seems to be working very reliably (i'll do more testing of course). Thanks for your reply anyway.
In one of the recent postings Peter said:

My understanding is merely that you will have some client-side "Data-like object" in networked mode. (I suspect that Sun included this requirement to force your architecture into a certain direction; there have been a number of posts about this). This object will have constructors that are different from those of Data for the simple reason that the networked mode works completely differently.
My understanding is also that there is a requirement for this object to exist. That doesn't mean you have to write that class yourself; an rmic-generated class can well satisfy the requirement. I personally used RMI in my project, and had a server-side Remote class implementing the Data interface. The rmic-generated stub for this class satisfies the requirement quoted above in every respect.

If i use a ConnectionFactory (which is a valid remote object) to return to me a RemoteData object (which does implement the Data interface), the only rmic-generated classes will be those for ConnectionFactory, NOT for the RemoteData. I was also under the impression (unless i am mistaken) that Peter implemented his client-ID scheme using a similar approach (Connection obect is a remote one, it's exposed for access and when clients get a hold of it, they ask it to return some kind of "RemoteData" object to each client to act as a client-ID along with it's other functions). This RemoteData object is not a remote object, in the sense ConectionFactory is, so there are no rmic-generated files to act as this client-side "proxy" object mentioned in Peter's quote above (and specified in the the requirements, of course). So how did Peter accomplish this task, i don't understand? Any comment is appreciated.
hmm, looks pretty simple but i have no idea what you're trying to do here. Can you please add some clarifying comments?
Poorna Lakki,
You can return whatever you want for a "non-match". I arranged for a return of an empty DataInfo[], whose length (length = 0) indicates that there were no records to match the input string.
k, several things upfront:
** You WILL have to learn precisely how regex works in java. Here is a good tutorial link
regex torial from Sun.
** Note there are some subtle differences between regular expressions in different languages. So, no universal standard.
** Pay particular attention to when you should use Greedy, Reluctant and Possessive quantifiers. It's critically important - means difference
between a working regular expressions and a regular expressions which looks like it SHOULD work, yet it DOESN't -
the most likely reason is in how you use the quantifiers. So learn about them in detail.
** You will need a test harness to try out your regular expressions in an easy way - the tutorial luckly has one for you to download.
It's a good one.
Ok, here are some ideas about how i did it which can help you get started once you learn enough about how regex works in java:
(NOTE: if you don't understand something,don't get stuck, just keep reading - i try to reiterate some important points, so you'll
see me talk about them again)
criteriaFind(String criteria) {
/*PHASE NUMBER 1 (better to put it in a separate function: String [] func1(String criteria) ):
separate the criteria into its constituent elements with "any character" regex prepended and postfixed to them; for example: "criteria=Origin airport='ABC',Destination airport='DFG'" yeilds an array of strings:
.*?Origin airport='ABC'.*?
.*?Destination airport='DFG'.*?
To get this result, you need to come up with a regex which matches a correct criteria input string. If the criteria is wrong, your
regex (if constructed properly) will NOT match it. Note, you will need to use the group() function after that in the Matcher class to obtain all the key='value' pairs. As soon as you get a pair, prepend it and postfix it with .*? - a "any number of any characters" match (we will see why we need it later). So eventually, you will be able to get all of these .*?fieldname='value'.*? (or .*?key='value'.*? as i called it before) and store it in an array of strings. Then func1() returns all of them in a String[].
Basically func1() is using regex (designed by you) to construct a bunch or regex's (those stored in a String[] returned by func1()) we will use to do more matching later.
ok, let's review func1() in brief one more time (i understand, it's very tricky):
1) Create a regex which represents a correct
input for criteria.
2) Try to match your criteria against this regex. If it doesn't match, return new String[0];
This is the most heavyweight regex in this whole deal. Carefully think it through (hint: think of the most general correct value for your criteria).
3) Ok, now the criteria is correct (no weird characters, or wrong format). So use another regex (a much much smaller one) to pick out all the fieldname='value' pairs, prepend and postfix each one of them with .*? and put it in the next available String slot in your String[]. This procedure will use the group() method in the Matcher class.
//do the actual record matching here
synchronized (this) {
//needs to be synchronized to make sure noone attempts to change the reccount by adding or deleting records.
for (every record in the database) {
/*PHASE NUMBER 2: (String func2(DataInfo rec)) puts rec into key1='value1'key2='value2'key3='value3' ..... format and returns it as one large String (let's call it str)*/
for (every one of those .*?key='value'.*? pairs we obtained above) {
/*match it with str. If match is not found break out of this loop to go to the next record. If all the patterns matched a given record, that means all the key='value' pairs in the original criteria were present in this record, so grab this record and put it in some storage (a Vector, maybe)*/
/*create DataInfo[] out of that storage (the one containing all the matched records) and return it.*/
Poorna Lakki,
You can use whatever you want to do the matching in criteria find. I used regex because it automatically checks for many different cases and makes sure your input string is correct. The matching is done in in fewer lines of code (although, the regular expressions themselves can be quite cryptic).